[MacRuby-devel] #init, or #initialize
Hi It seems on MacRuby 0.8 that a subclass of NSWindowController has #init called, but #initialize is not called. It seems really odd to have two different initialize methods, and particularly when one of them breaks away from what is convention in Ruby. Is this intended? Thanks Rob ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] #init, or #initialize
I use #init whenever I’m dealing with Cocoa(-like) classes and #initialize when it's pure Ruby. I do the same with regards to camel and snake casing. Also note that #init is not supposed to take arguments, whereas #initialize may definitely do so. Any classes that inherit from NSObject directly will have #initialize called if #init is called on them: % cat t.rb class PureRubyClass def initialize puts "here!" end end PureRubyClass.alloc.init % macruby t.rb here! On Feb 24, 2011, at 1:46 PM, Rob Gleeson wrote: > Hi > > It seems on MacRuby 0.8 that a subclass of NSWindowController has #init > called, but #initialize is not called. > It seems really odd to have two different initialize methods, and > particularly when one of them breaks away from > what is convention in Ruby. Is this intended? > > > Thanks > Rob > > > > > > ___ > 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] #init, or #initialize
On 24 Feb 2011, at 13:26, Eloy Durán wrote: > I use #init whenever I’m dealing with Cocoa(-like) classes and #initialize > when it's pure Ruby. I do the same with regards to camel and snake casing. > Also note that #init is not supposed to take arguments, whereas #initialize > may definitely do so. > > Any classes that inherit from NSObject directly will have #initialize called > if #init is called on them: > > % cat t.rb > class PureRubyClass > def initialize >puts "here!" > end > end > > PureRubyClass.alloc.init > > % macruby t.rb > here! > Alright, thanks for clarifying. The camelCase and snake_case difference is something I've been trying to get use to as well. I think I'll adopt your style :) -- Rob ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] MacRuby 0.8 EXC_BAD_ACCESS using NSPredicate against Core Data
Hi, I'm trying to apply a predicate to a core data fetch and hitting
EXC_BAD_ACCESS.
I've successfully used NSPredicate to filter an array's contents, but all my
attempts to use NSPredicate with Coredata fail.
I'm using framework 'Coredata' and framework 'Foundation' and this is the
method that fails:
def tagEntityExists?(tag, moc)
puts 'NodeProxy:tagEntityExists?'
entityDescription = NSEntityDescription.entityForName('Tag',
inManagedObjectContext:moc)
request = NSFetchRequest.alloc.init()
request.setEntity(entityDescription)
puts "Looking for tag: #{tag}"
predicate = NSPredicate.predicateWithFormat("name == %@", tag)
request.setPredicate(predicate)
error = Pointer.new(:id)
puts "request: #{request.description}"
begin
results = moc.executeFetchRequest(request, error:error)
rescue Exception => bang
puts bang
end
unless results
puts "Fetch failure: #{error.description}"
return nil
end
puts "Will return: #{results.inspect}"
return results[0]
end
and here's the backtrace I get:
#0 0x7fff86ef42bc in _qfqp2_InitializedGlobalData ()
#1 0x000102d61fe0 in ?? ()
#2 0x00010014a0b3 in rb_vm_dispatch ()
#3 0x000102d5ab26 in ?? ()
#4 0x000102d62c56 in ?? ()
#5 0x00010014bcd6 in rb_vm_dispatch ()
#6 0x000102d5ab26 in ?? ()
#7 0x000102d626da in ?? ()
#8 0x00010014e1f7 in rb_vm_yield_args ()
#9 0x000100102ad8 in rb_yield ()
#10 0x000100176f38 in rb_ary_freeze ()
#11 0x00010014bd16 in rb_vm_dispatch ()
#12 0x000102d5ab26 in ?? ()
#13 0x000102d62383 in ?? ()
#14 0x00010014bcd6 in rb_vm_dispatch ()
#15 0x000102d5ab26 in ?? ()
#16 0x000102d61906 in ?? ()
#17 0x00010014bcfb in rb_vm_dispatch ()
#18 0x000102d5ab26 in ?? ()
#19 0x000102d61542 in ?? ()
#20 0x00010014e1f7 in rb_vm_yield_args ()
#21 0x000100102ad8 in rb_yield ()
#22 0x000100176f38 in rb_ary_freeze ()
#23 0x00010014bd16 in rb_vm_dispatch ()
#24 0x000102d5ab26 in ?? ()
#25 0x000102d60c59 in ?? ()
#26 0x00010014bd16 in rb_vm_dispatch ()
#27 0x000102d5ab26 in ?? ()
#28 0x000102d6073d in ?? ()
#29 0x00010014bcfb in rb_vm_dispatch ()
#30 0x0001000f2bbe in rb_objc_isEqual ()
#31 0x0001000f2d8e in rb_objc_isEqual ()
#32 0x7fff837d1e9a in -[NSApplication sendAction:to:from:] ()
#33 0x7fff837f641e in -[NSMenuItem _corePerformAction] ()
#34 0x7fff837f6188 in -[NSCarbonMenuImpl
performActionWithHighlightingForItemAtIndex:] ()
#35 0x7fff83a7a279 in -[NSMenu _internalPerformActionForItemAtIndex:] ()
#36 0x7fff8392bf77 in -[NSCarbonMenuImpl
_carbonCommandProcessEvent:handlerCallRef:] ()
#37 0x7fff837d895c in NSSLMMenuEventHandler ()
#38 0x7fff8109b9d5 in DispatchEventToHandlers ()
#39 0x7fff8109af28 in SendEventToEventTargetInternal ()
#40 0x7fff810b8beb in SendEventToEventTarget ()
#41 0x7fff810e7d51 in SendHICommandEvent ()
#42 0x7fff81114b86 in SendMenuCommandWithContextAndModifiers ()
#43 0x7fff81114b3e in SendMenuItemSelectedEvent ()
#44 0x7fff81114a3e in FinishMenuSelection ()
#45 0x7fff810f5d13 in MenuSelectCore ()
#46 0x7fff810f5468 in _HandleMenuSelection2 ()
#47 0x7fff836a97dd in _NSHandleCarbonMenuEvent ()
#48 0x7fff8367d317 in _DPSNextEvent ()
#49 0x7fff8367c7a9 in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#50 0x7fff8364248b in -[NSApplication run] ()
#51 0x7fff8363b1a8 in NSApplicationMain ()
#52 0x000102d5ea5d in ?? ()
#53 0x00010014a658 in rb_vm_dispatch ()
#54 0x000102d5ab26 in ?? ()
#55 0x000102d5a4dc in ?? ()
#56 0x000100162d53 in rb_vm_run ()
#57 0x0001000408f0 in ruby_run_node ()
#58 0x00010015a332 in macruby_main ()
#59 0x00010f20 in main (argc=1, argv=0x7fff5fbff6c8) at
/Users/jonathan/Desktop/
Um, any suggestions? I see that there are previous list entries about this sort
of problem but I think there are now all closed
Many thanks and regards, Jonathan___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] MacRuby 0.8 EXC_BAD_ACCESS using NSPredicate against Core Data
Greetings,
What's the output up to the crash point?
I didn't realize you could do Pointer.new(:id), I'm still using
Pointer.new_from_type('@'). :)
Check entityDescription for nil, also. If for some reason it can't resolve
your entity it'll return nil, and that might blow up in a way like you're
seeing.
(Presuming the exception is being thrown from under executeFetchRequest.)
Just a few guesses from a fellow traveler on the Core Data highway. :/
-- Morgan
p.s. It could also be tweaked to be more Ruby-esque, but that won't help
with the problem...
On Thu, Feb 24, 2011 at 8:58 AM, Jonathan Waddilove
wrote:
> Hi, I'm trying to apply a predicate to a core data fetch and hitting
> EXC_BAD_ACCESS.
>
> I've successfully used NSPredicate to filter an array's contents, but all
> my attempts to use NSPredicate with Coredata fail.
>
> I'm using framework 'Coredata' and framework 'Foundation' and this is the
> method that fails:
>
> def tagEntityExists?(tag, moc)
> puts 'NodeProxy:tagEntityExists?'
> entityDescription = NSEntityDescription.entityForName('Tag',
> inManagedObjectContext:moc)
> request = NSFetchRequest.alloc.init()
> request.setEntity(entityDescription)
>
> puts "Looking for tag: #{tag}"
> predicate = NSPredicate.predicateWithFormat("name == %@", tag)
> request.setPredicate(predicate)
>
> error = Pointer.new(:id)
>
> puts "request: #{request.description}"
> begin
> results = moc.executeFetchRequest(request, error:error)
> rescue Exception => bang
> puts bang
> end
>
> unless results
> puts "Fetch failure: #{error.description}"
> return nil
> end
> puts "Will return: #{results.inspect}"
> return results[0]
> end
>
> and here's the backtrace I get:
>
> **
> #0 0x7fff86ef42bc in _qfqp2_InitializedGlobalData ()
> #1 0x000102d61fe0 in ?? ()
> #2 0x00010014a0b3 in rb_vm_dispatch ()
> #3 0x000102d5ab26 in ?? ()
> #4 0x000102d62c56 in ?? ()
> #5 0x00010014bcd6 in rb_vm_dispatch ()
> #6 0x000102d5ab26 in ?? ()
> #7 0x000102d626da in ?? ()
> #8 0x00010014e1f7 in rb_vm_yield_args ()
> #9 0x000100102ad8 in rb_yield ()
> #10 0x000100176f38 in rb_ary_freeze ()
> #11 0x00010014bd16 in rb_vm_dispatch ()
> #12 0x000102d5ab26 in ?? ()
> #13 0x000102d62383 in ?? ()
> #14 0x00010014bcd6 in rb_vm_dispatch ()
> #15 0x000102d5ab26 in ?? ()
> #16 0x000102d61906 in ?? ()
> #17 0x00010014bcfb in rb_vm_dispatch ()
> #18 0x000102d5ab26 in ?? ()
> #19 0x000102d61542 in ?? ()
> #20 0x00010014e1f7 in rb_vm_yield_args ()
> #21 0x000100102ad8 in rb_yield ()
> #22 0x000100176f38 in rb_ary_freeze ()
> #23 0x00010014bd16 in rb_vm_dispatch ()
> #24 0x000102d5ab26 in ?? ()
> #25 0x000102d60c59 in ?? ()
> #26 0x00010014bd16 in rb_vm_dispatch ()
> #27 0x000102d5ab26 in ?? ()
> #28 0x000102d6073d in ?? ()
> #29 0x00010014bcfb in rb_vm_dispatch ()
> #30 0x0001000f2bbe in rb_objc_isEqual ()
> #31 0x0001000f2d8e in rb_objc_isEqual ()
> #32 0x7fff837d1e9a in -[NSApplication sendAction:to:from:] ()
> #33 0x7fff837f641e in -[NSMenuItem _corePerformAction] ()
> #34 0x7fff837f6188 in -[NSCarbonMenuImpl
> performActionWithHighlightingForItemAtIndex:] ()
> #35 0x7fff83a7a279 in -[NSMenu _internalPerformActionForItemAtIndex:]
> ()
> #36 0x7fff8392bf77 in -[NSCarbonMenuImpl
> _carbonCommandProcessEvent:handlerCallRef:] ()
> #37 0x7fff837d895c in NSSLMMenuEventHandler ()
> #38 0x7fff8109b9d5 in DispatchEventToHandlers ()
> #39 0x7fff8109af28 in SendEventToEventTargetInternal ()
> #40 0x7fff810b8beb in SendEventToEventTarget ()
> #41 0x7fff810e7d51 in SendHICommandEvent ()
> #42 0x7fff81114b86 in SendMenuCommandWithContextAndModifiers ()
> #43 0x7fff81114b3e in SendMenuItemSelectedEvent ()
> #44 0x7fff81114a3e in FinishMenuSelection ()
> #45 0x7fff810f5d13 in MenuSelectCore ()
> #46 0x7fff810f5468 in _HandleMenuSelection2 ()
> #47 0x7fff836a97dd in _NSHandleCarbonMenuEvent ()
> #48 0x7fff8367d317 in _DPSNextEvent ()
> #49 0x7fff8367c7a9 in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] ()
> #50 0x7fff8364248b in -[NSApplication run] ()
> #51 0x7fff8363b1a8 in NSApplicationMain ()
> #52 0x000102d5ea5d in ?? ()
> #53 0x00010014a658 in rb_vm_dispatch ()
> #54 0x000102d5ab26 in ?? ()
> #55 0x000102d5a4dc in ?? ()
> #56 0x000100162d53 in rb_vm_run ()
> #57 0x0001000408f0 in ruby_run_node ()
> #58 0x00010015a332 in macruby_main ()
> #59 0x00010f20 in main (argc=1, argv=0x7fff5fbff6c8) at
> /Users/jonathan/Desktop/
>
> Um, any suggestions? I see that there are previous list entries about this
> sort of problem but I think there are now all closed
>
>
> Many thanks and regards, Jonathan
>
> ___
> MacRuby-devel mailing list
> [email protected]
Re: [MacRuby-devel] loop audio file seamlessly (Zachary Kaplan)
Hi Zak,
I'm running MacRuby revision 5236 with BridgeSupport Preview 3 and the
following script works fine:
framework 'AudioToolbox'
url = NSURL.fileURLWithPath "/test/loops/Lounge Vibes 01.caf"
audioFileID_ptr = Pointer.new_with_type '^{OpaqueAudioFileID}'
p AudioFileOpenURL url, KAudioFileReadPermission, 0, audioFileID_ptr
HTH,
Ed
On Feb 23, 2011, at 1:27 AM, Zachary Kaplan wrote:
> hello all,
>
> i received a suggestion from another member to check out the PlayFile
> example in the audio toolbox examples.
>
> while this was very helpful in putting me on the right track for basic
> low level audio manipulation, there are some additional related issues
> i've encountered in trying to port over the example to macruby.
>
> most notably, i don't seem to have some of the most important methods
> available such as AudioFileOpenURL.
>
> perhaps (most likely) i am just doing something wrong. i have bridge support
> 2.
>
> also if anyone has any macruby audio examples, i'd love to see what
> others have done.
>
> could anyone else provide some more insight?
>
> thanks in advance
> -zak
> ___
> 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] stopping to build for i386
On Tue, Feb 22, 2011 at 8:31 PM, Laurent Sansonetti wrote: > Hi, > As of r5239 in trunk, the default build process will no longer build for > both i386 and x86_64, but just x86_64. This is an attempt at accelerating > the build process and reducing the framework objects size. > We are however not removing any i386-related code from the project, and one > will still be able to build a 32-bit version of MacRuby by passing > archs=i386 to rake. We will also consider fixing i386 bugs. But we want to > start discouraging people to target i386 hardware for MacRuby apps, for > several reasons (codebase not well tested, runtime / exception handling > differences, floating point precision loss, etc.). The i386-related code > could eventually be removed from MacRuby after 0.10. > This is not an irrevocable decision, though. If people complain we will > revert the change. But I want to give it a try. > Laurent How hard do you imagine it would be for other developers to keep the 386 code going after 0.10? ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] 0.9 update
On Wed, Feb 23, 2011 at 6:51 PM, Laurent Sansonetti wrote: > Are you using the new macruby_deploy --gem option to embed the gems? > I'm not ... I'm using macruby_deploy --embed to embed MacRuby, and then my own custom Rake task to 1) copy the gem files into the application; 2) run install_name_tool on the embedded bundle files. I guess I should look into the --gem option. ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
