Re: [MacRuby-devel] Will FFI make it into macruby?
We don't really have a choice, the C API does not offer all the features we need and we also need to follow the new LLVM changes internally. Hopefully, the LLVM team is always helping us :-) I wouldn't expect you to use the C API internally, but it's convenient to wrap it with FFI. That's how bindings were created for e.g. Lua and Ocaml. Linkage may also be problematic since my FFI bindings depend on LLVM dylibs. I'm not sure how they would work with MacRuby yet. It will very likely collide at runtime... until we un-export all symbols (but the C extension ones) from the link phase, which should happen in theory for our next release, 0.6. That sounds promising. Thanks for the explanation. Best, Jeremy 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] Will FFI make it into macruby?
On Wed, Mar 17, 2010 at 2:02 AM, Laurent Sansonetti lsansone...@apple.comwrote: Hi Robert, There is currently no plan about implementing the FFI API in MacRuby. It was my plan originally but apparently the API is not really used, so I preferred to support C extensions instead, which will be in the next release, 0.6. Ouch! I'm getting ready to make an initial release of FFI bindings to LLVM 2.6. So far they run on MRI 1.8.7, 1.9.1, and JRuby. I'd very much like to use them with MacRuby as well. At a minimum, they require attach_function, MemoryPointer and enums. I'll also readily admit that lack of FFI is the biggest reason I've *not* been using MacRuby for my current projects, as well as why my bindings don't have thorough support for managing LLVMContexts. I see that MacRuby uses llvm/ModuleProvider.h which is removed in LLVM 2.7. Am I right in assuming that MacRuby requires LLVM 2.6, and will this be the case for the forseeable future? Best Jeremy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Will FFI make it into macruby?
We already have a basic implementation of attach_function in MacRuby based on LLVM, but it has not been tested well. And we have a class similar to MemoryPointer too (called Pointer) which also uses LLVM to generate conversion stubs. I think it shouldn't be hard to finish FFI inside MacRuby, it's just that I'm the only person really working on the project so far and this isn't very high on the TODO list. If one wants to help... :-) Implementing FFI in terms of existing BridgeSupport makes sense, and afaik Rubinius' FFI support also depends heavily on their LLVM JIT compiler, so it seems like a good approach. MacRuby is progressively following LLVM. However we do at the moment require a revision where ModuleProvider.h exists (I have a local patch that makes it work for future revisions too but it's not applied yet). # The LLVM_TOT variable can be passed to rake in order to sometimes build with more recent revisions than the one specified in the README.rdoc file, but it is only used for internal development and targets a special internal branch of LLVM, so it might not always work against the public trunk. Ideally we will target the final 2.7 once it's out, which shouldn't be long now. Do you intend to continue progressively tracking LLVM? LLVM-trunk is such a moving target, but so long as the llvm-c interface stays compatible this is no problem. Linkage may also be problematic since my FFI bindings depend on LLVM dylibs. I'm not sure how they would work with MacRuby yet. Best, Jeremy 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] [MacRuby] #528: Improve Tail Call Elimination
So, can the TCO elimination pass actually perform TCO for mutually recursive methods and the compiler just isn't phrasing method invocations in a compatible way? Also, better method inlining support is awesome, but my intuition tells me that there isn't a lot of overlap between implementing TCO and inlining. Laurent, is there something I can learn from this? :) Best, Jeremy On Mon, Jan 4, 2010 at 2:50 PM, MacRuby ruby-nore...@macosforge.org wrote: #528: Improve Tail Call Elimination -+-- Reporter: haruki.zae...@… | Owner: lsansone...@… Type: enhancement | Status: new Priority: minor| Milestone: Component: MacRuby |Keywords: tail call elimination optimisation tco -+-- Comment(by haruki.zae...@…): Replying to [comment:13 lsansone...@…]: We should be able to do much more sophisticated tall call elimination with the new VM changes I'm working on (which allow method inlining). I will investigate that, for 0.6. Sounds great. My C++ is 15 years old so I suspect I'm of no help. Thanks for listening anyway :) -- Ticket URL: http://www.macruby.org/trac/ticket/528#comment:14 MacRuby http://macruby.org/ ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] How to test if you're running MacRuby vs. Ruby?
i.e. the argument to defined? must be put in parentheses else MacRuby crashes. Only because binds more tightly than method application. It would be nice if some of this code found its way into the Platform gem, or similar. I've found myself writing Kernel#macruby? in libraries a couple of times. Paul Howson ___ 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] Should the HotCocoa example on the home page run on 0.5 beta 2?
I've just installed the latest MacRuby beta binaries on my new macbook, and
this happens:
Jeremy-Voorhiss-MacBook-Pro:~ jvoorhis$ cat test.rb
require 'hotcocoa'
include HotCocoa
application do |app|
win = window :size = [100,50]
b = button :title = 'Hello'
b.on_action { puts 'World!' }
win b
end
Jeremy-Voorhiss-MacBook-Pro:~ jvoorhis$ macruby --version
MacRuby version 0.5 (ruby 1.9.0) [universal-darwin10.0, x86_64]
Jeremy-Voorhiss-MacBook-Pro:~ jvoorhis$ macruby test.rb
2009-12-18 22:06:45.181 macruby[76926:903] *** -[NSLock unlock]: lock
(NSLock: 0x2000a9600 '(null)') unlocked when not locked
2009-12-18 22:06:45.184 macruby[76926:903] *** Break on _NSLockError() to
debug.
/Library/Frameworks/MacRuby.framework/Versions/0.5/usr/lib/ruby/1.9.0/hotcocoa/mappings/application.rb:9:in
`handle_block:': undefined method `on_action' for 0:NSButton (NoMethodError)
from core:in `application:'
from test.rb:2:in `main'
I've hardly used HotCocoa at all. This might have already been covered in
some other thread that I wasn't paying attention to. If not, I can file
something in trac.
Thanks,
Jeremy
___
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?
When MacRuby's FFI support is more mature, declaring an FFI::Struct subclass like this will be another option. class MapPoint FFI::Struct layout :row, :int, :col, :Int end You instantiate an FFI::Struct with a pointer. I'm hacking away on a Ruby interface to a C library, and I'm slinging around pointers, structs and unions with ease on MRI 1.8.6, 1.9.1 and JRuby. Best, Jeremy On Wed, Aug 5, 2009 at 8:41 AM, Eloy Duran eloy.de.en...@gmail.com wrote: 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] question about goals for ruby module compatibility with macruby
If MacRuby is aiming for full FFI support, a la JRuby, then creating interpreter-independent versions of C extensions need not be difficult. I've begun porting some of my own Ruby bindings from DL and C and have found that as long as you handle your C types correctly, everything tends to Just Work on MRI versions 1.8.6, 1.9.1, and recent versions of JRuby. To my knowledge, the macruby-experimental branch only supports attaching C functions (e.g. no structs, callbacks), but that is likely to improve. The FFI documentation is also a little thin, but it's easy to pick up once you've seen some examples. Here's a CoreMIDI driver I've ported to FFI: http://github.com/jvoorhis/midiator/blob/4e6024b8e68503868272770d8c8ecabe02445f85/lib/midiator/drivers/core_midi.rb Best, Jeremy On Thu, Jul 30, 2009 at 10:09 AM, Matt Aimonetti mattaimone...@gmail.comwrote: Hi Tim, I was about to reply to your colleague, Mr Otero, so let me try to clarify a few things that might help others. The goal for MacRuby 0.5 is to be able to run any rubygems that are not C extensions. ( see Macruby 0.5 roadmap: http://lists.macosforge.org/pipermail/macruby-devel/2009-July/002091.html) The good news is that the BioRuby gem is pure Ruby, the bad news is that it's not fully compatible with Ruby 1.9 yet. (MacRuby is aiming for Ruby 1.9 compatibility) However, that shouldn't be hard to fix. Regarding Rails, that's a different story, as you probably know, Rails 3 is going to be released towards the end of the year. Rails is a big project and quite a challenging one to have running on top of any Ruby implementation. The primarily goal of MacRuby is to let people write Cocoa apps in Ruby, so Rails is not at the top of the todo list. However, this is something we would really like to be able to do ASAP. (being part of the Rails team, I would love to see that happen). Rails also uses some C based extensions like its DB drivers and we would need to find workarounds. I hope it helps, - Matt On Thu, Jul 30, 2009 at 9:36 AM, Tim Rand timra...@gmail.com wrote: Hi Laurent and macruby-ists,I am thinking about taking on a rather ambitious project with macruby in the next year or so which would benefit from having access to existing ruby gems (like the bioruby gem and rails). Can anyone predict how general the ruby gem compatibility will be as macruby matures? I promise I won't hold anyone responsible for their speculation. Tim ___ 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] Using performRubySelector
Mike,
Is your code available anywhere, e.g. on github? I haven't looked at
the PyObjC code myself, but I'd be interested in having really decent
CoreMIDI support available in MacRuby.
Btw, when C extensions are supported, simple apps will be able to use
my MusicPlayer lib at
http://github.com/jvoorhis/music_player/tree/master, which wraps much
of the MusicPlayer/MusicSequence api in AudioToolbox.framework. It's
short on documentation, but it's easy to get up and running on MRI
1.8.x or 1.9.1.
Best,
Jeremy
On Wed, May 27, 2009 at 11:25 PM, Mike Laurence mklaure...@gmail.com wrote:
Hmmm... I'm doing several things different, perhaps one or more of
them are impossible :-)
Basically, I'm trying to get MIDI support into Ruby via the PYMIDI
obj-c library, which is really just a wrapper around CoreMIDI. One way
I had thought of: create an additional obj-c class (MidiReceiver)
which processes incoming packets for a given MIDI source and then call
methods such as note, controlChange, clockTick, etc. This
MidiReceiver class can then be overridden by a custom ruby class that
contains those same methods.
Here is a quick version of the MidiReceiver class (with only the
clockTick method for simplicity):
- MidiReceiver --
#import MacRuby/MacRuby.h
#include CoreMIDI/CoreMIDI.h
@interface MidiReceiver : NSObject
- (void) processMIDIPacket: (MIDIPacket*) packet;
- (void) clockTick;
@end
@implementation MidiReceiver
- (void) processMIDIPacket: (MIDIPacket*) packet {
if (packet-length 0) {
int statusByte = packet-data[0];
int status = statusByte = 0xf0 ? statusByte : statusByte 4 4;
switch (status) {
case 0x90: // Note on, etc...
case 0xf8: // Clock tick
[self performRubySelector:@selector(clockTick)];
break;
}
}
}
- (void) clockTick {
}
@end
Then, I have a ruby subclass of MidiReceiver that overrides clockTick, etc.:
class LiveMidiReceiver MidiReceiver
def clockTick
puts tick!
end
end
And then, in my Ruby ApplicationController, I'm finding the MIDI
source and adding an instance of LiveMidiReceiver as a MIDI receiver:
@src = PYMIDIManager.sharedInstance.realSources.find{ |s|
s.displayName == 'KONTROL49 PORT A' }
receiver = LiveMidiReceiver.new
@src.addReceiver(receiver)
The LiveMidiReceiver instance, upon receiving a midi packet, is called
properly up to the point of the performRubySelector, but thereafter it
launches into the debugger with EXC_BAD_ACCESS messages or other
unsightly stack dumps.
---
An even *better* interface would be to have the clockTick and other
calls be performable on an arbitrary ruby object without having to
subclass MidiReceiver (e.g., have MidiReceiver send clockTick, etc.
to a delegate object which has been created solely in Ruby). I tried
that and it gave me similar results, although strangely it only
crashed the first time on a clean build - thereafter I saw no crashes,
but still no confirmation of ruby method calls either.
To test that, I just added a delegate object to MidiReceiver, and then
I changed the clockTick recipient from self to delegate:
[delegate performRubySelector:@selector(clockTick)];
Then set receiver.delegate = self in my ApplicationController. I'll
bet I need some more hooks than that, although it sure would be nice
to send ruby messages from obj-c willy-nilly :-)
---
I hope I'm making some sense here! I greatly appreciate any info that
you can send my way. Hopefully when I get this all figured out I can
write a nice, fat blog post about it :-)
Regards,
Mike Laurence
On Wed, May 27, 2009 at 8:18 PM, Laurent Sansonetti
lsansone...@apple.com wrote:
Hi Mike,
On May 26, 2009, at 5:45 PM, Mike Laurence wrote:
Hello,
I'm trying to get some obj-c code to talk back to my ruby. After
encountering some EXC_BAD_ACCESS messages and scouring the web, I've
concluded that I'm probably supposed to use performRubySelector
instead of just expecting selectors to work when overridden by ruby
subclasses, etc.
What is the preferred way to get this to work? I looked through some
of Elysium's old code (which used performRubySelector), but I'm having
trouble wrapping my head around how you're supposed to use the MacRuby
sharedRuntime to get things to happen. If someone could give me a
quick example of how to call arbitrary ruby methods, I would highly
appreciate it.
Of course, if I'm completely off base and there's some other way to
call ruby code, please let me know!
Calling Ruby from Objective-C can be problematic, depending if you want to
call a pure Ruby method or a Ruby method that overrides an Objective-C one.
If you want to dispatch the method by yourself (and if it's a Ruby method
that overrides a specialized Objective-C method), you may want to be very
careful about the types of the arguments you are
Re: [MacRuby-devel] Using performRubySelector
I'd love to do it in FFI, but getting this far in C was a lot of work!
... so here's another crackpot idea of mine. Another project I have
been following is the Pure Language
http://code.google.com/p/pure-lang. It aims to be a simple,
interpreted functional language based on term-rewriting, and also has
an LLVM JIT compiler. Using LLVM, they support a literal syntax for
declaring foreign functions.
To assist in creating wrappers for libraries, they created a tool
called pure-gen that parses C header files and dumps out a .pure file
containing FFI declarations. The tool is written in Haskell using a
module called Language.C, but I wonder if we could bootstrap something
similar by wrapping up Clang's libparse. They've managed to create
wrappers for gsl, gtk+ and some other libraries by starting with the
generated FFI decls, and adding some syntactic sugar and abstraction
within Pure as appropriate.
Implementing such a tool is probably going to take a lot of effort,
but the benefits are pretty clear – especially since generated
wrappers might be usable in JRuby and MRI. I also don't know how much
this overlaps with BridgeSupport, but I just wanted to put the idea
out there.
Best,
Jeremy
On Thu, May 28, 2009 at 10:38 AM, Matt Aimonetti
mattaimone...@gmail.com wrote:
I second what Jeremy said. A nice Midi wrapper would be great.
Jeremy, regarding your MusicPlayer lib, the other option is to port it to
FFI and therefore making it JRuby and MacRuby compatible.
- Matt
On Thu, May 28, 2009 at 10:32 AM, Jeremy Voorhis jvoor...@gmail.com wrote:
Mike,
Is your code available anywhere, e.g. on github? I haven't looked at
the PyObjC code myself, but I'd be interested in having really decent
CoreMIDI support available in MacRuby.
Btw, when C extensions are supported, simple apps will be able to use
my MusicPlayer lib at
http://github.com/jvoorhis/music_player/tree/master, which wraps much
of the MusicPlayer/MusicSequence api in AudioToolbox.framework. It's
short on documentation, but it's easy to get up and running on MRI
1.8.x or 1.9.1.
Best,
Jeremy
On Wed, May 27, 2009 at 11:25 PM, Mike Laurence mklaure...@gmail.com
wrote:
Hmmm... I'm doing several things different, perhaps one or more of
them are impossible :-)
Basically, I'm trying to get MIDI support into Ruby via the PYMIDI
obj-c library, which is really just a wrapper around CoreMIDI. One way
I had thought of: create an additional obj-c class (MidiReceiver)
which processes incoming packets for a given MIDI source and then call
methods such as note, controlChange, clockTick, etc. This
MidiReceiver class can then be overridden by a custom ruby class that
contains those same methods.
Here is a quick version of the MidiReceiver class (with only the
clockTick method for simplicity):
- MidiReceiver --
#import MacRuby/MacRuby.h
#include CoreMIDI/CoreMIDI.h
@interface MidiReceiver : NSObject
- (void) processMIDIPacket: (MIDIPacket*) packet;
- (void) clockTick;
@end
@implementation MidiReceiver
- (void) processMIDIPacket: (MIDIPacket*) packet {
if (packet-length 0) {
int statusByte = packet-data[0];
int status = statusByte = 0xf0 ? statusByte : statusByte 4
4;
switch (status) {
case 0x90: // Note on, etc...
case 0xf8: // Clock tick
[self performRubySelector:@selector(clockTick)];
break;
}
}
}
- (void) clockTick {
}
@end
Then, I have a ruby subclass of MidiReceiver that overrides clockTick,
etc.:
class LiveMidiReceiver MidiReceiver
def clockTick
puts tick!
end
end
And then, in my Ruby ApplicationController, I'm finding the MIDI
source and adding an instance of LiveMidiReceiver as a MIDI receiver:
@src = PYMIDIManager.sharedInstance.realSources.find{ |s|
s.displayName == 'KONTROL49 PORT A' }
receiver = LiveMidiReceiver.new
@src.addReceiver(receiver)
The LiveMidiReceiver instance, upon receiving a midi packet, is called
properly up to the point of the performRubySelector, but thereafter it
launches into the debugger with EXC_BAD_ACCESS messages or other
unsightly stack dumps.
---
An even *better* interface would be to have the clockTick and other
calls be performable on an arbitrary ruby object without having to
subclass MidiReceiver (e.g., have MidiReceiver send clockTick, etc.
to a delegate object which has been created solely in Ruby). I tried
that and it gave me similar results, although strangely it only
crashed the first time on a clean build - thereafter I saw no crashes,
but still no confirmation of ruby method calls either.
To test that, I just added a delegate object to MidiReceiver, and then
I changed the clockTick recipient from self to delegate:
[delegate performRubySelector:@selector(clockTick
Re: [MacRuby-devel] A MacRuby-users group?
Personally, I'm in favor of a single mailing list, especially with a small group like this. If there is some perception that a name ending in -devel is intimidating, maybe we should just be pitched as the MacRuby mailing list :) Best, Jeremy On Fri, May 22, 2009 at 10:35 AM, Laurent Sansonetti lsansone...@apple.com wrote: Hi Łukasz, This mailing-list was usually created for all people developing with MacRuby, not necessarily people developing MacRuby itself. But I can understand that the group name is ambiguous. Just to let everyone know, there is absolutely no problem posting anything related to MacRuby on this list. It's also true that there are more users discussions than core discussions here, but this might change once we get more people involved in the project. I think that the list traffic is still very light so I wonder if we need 2 separate lists. Any though? If most people agree to create a -users group I can ask for an official (macosforge.org) one. Laurent On May 22, 2009, at 10:09 AM, Łukasz Adamczak wrote: I'd like to propose the creation of macruby-users mailing list or an appropriate discussion board (the latter maybe even preferred). I'm thinking of a place for people using MacRuby for their apps, but not necessarily hacking on MacRuby itself. It feels a little intimidating to post to a -devel group, and I feel even I might be of some help to folks at a -users group. I don't mind starting something myself, but maybe an official discussion board is on the way. -- Regards, Łukasz Adamczak ___ 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] Erb ...
ERB is part of Ruby's core library, and as such, is included with MacRuby. I just poked around in macirb 0.4 and it seems to be working as expected. Best, Jeremy On Thu, May 21, 2009 at 2:57 AM, Mic Pringle micprin...@gmail.com wrote: Hi, Is Erb included in 0.4 MacRuby ... and if so is it fully functional ? Thanks, -Mic ___ 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] Key-value observing
Binding should work through Interface Builder, but I was only speaking
of the example in the original post. Traditional-style attr_writers
invoked by Ruby code bypass key-value observers, but it seems
intuitive to me to allow them to notify observers given how pervasive
key-value coding is in Cocoa, and that the infrastructure is
implemented in the base class for every object in the MacRuby runtime.
Best,
Jeremy Voorhis
On Fri, May 15, 2009 at 12:42 AM, Thilo th...@upstream-berlin.com wrote:
Isn't it already working? At least for primitiv types?
Eg. when I bind a label to a Int property which i change with a slider bind
to the same property i don't need additional code for KVO.
Cheers
Thilo
On 13.05.2009 22:31 Uhr, Jeremy Voorhis wrote:
I've created a ticket at https://www.macruby.org/trac/ticket/252. I
might be wrong as I am still grokking the Objective-C runtime, but it
seems to me that this should be easy to implement if attr_accessor and
attr_writer generate the setKey: method first and then implement #key=
in terms of setKey:. Is there some requirement that key-value setter
methods return void, or is that just by convention?
Best,
Jeremy
On Wed, May 13, 2009 at 12:00 PM, Laurent Sansonetti
lsansone...@apple.com wrote:
Hi Jeremy,
That's a pretty good idea! Could you file a bug on the tracker so that we
do
not forget about it?
Thanks,
Laurent
On May 12, 2009, at 10:18 AM, Jeremy Voorhis wrote:
Hello,
I've been learning Cocoa, Objective-C and macruby in tandem and I was
just wondering, are there any plans to integrate the key-value
observing protocol with the attr_accessor family of methods? With a
little experimentation, I found KVO is definitely possible with
macruby, but the syntax is less than ideal (transcript made with the
0.4 release).
~ % macirb
class Notifier
attr_accessor :value
end
= nil
class Observer
def observeValueForKeyPath(path, ofObject:object, change:change,
context:context) puts change end
end
= nil
n = Notifier.new
= #Notifier:0x8005e91a0
n.addObserver(Observer.new, forKeyPath:'value', options:0,
context:nil)
= nil
n.value = 42
= 42
n.setValue 42
{kind=1}
= nil
Best,
Jeremy Voorhis
___
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] Status of Fiber support?
On Thu, May 14, 2009 at 11:43 AM, Matt Aimonetti mattaimone...@gmail.com wrote: Jeremy, I would create a ticket, at least people encountering the same problem would be able to easily find a report of the problem. Right on. I've posted a ticket at https://www.macruby.org/trac/ticket/253 so we can keep tabs on this. Thanks for the additional examples. On Thu, May 14, 2009 at 11:10 AM, Jeremy Voorhis jvoor...@gmail.com wrote: Hello, I've just noticed that, at least in 0.4, Fiber#resume causes a segfault. I found this ticket in trac which obliquely addresses the issue: https://www.macruby.org/trac/ticket/81. Laurent: would a new ticket for this issue be helpful or noisy in this case? Best, Jeremy Voorhis ___ 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] Key-value observing
Hello,
I've been learning Cocoa, Objective-C and macruby in tandem and I was
just wondering, are there any plans to integrate the key-value
observing protocol with the attr_accessor family of methods? With a
little experimentation, I found KVO is definitely possible with
macruby, but the syntax is less than ideal (transcript made with the
0.4 release).
~ % macirb
class Notifier
attr_accessor :value
end
= nil
class Observer
def observeValueForKeyPath(path, ofObject:object, change:change,
context:context) puts change end
end
= nil
n = Notifier.new
= #Notifier:0x8005e91a0
n.addObserver(Observer.new, forKeyPath:'value', options:0, context:nil)
= nil
n.value = 42
= 42
n.setValue 42
{kind=1}
= nil
Best,
Jeremy Voorhis
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
