[MacRuby-devel] [MacRuby] #629: Bindings not working for subclass

2010-03-06 Thread MacRuby
#629: Bindings not working for subclass
-+--
 Reporter:  dy...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:   
Component:  MacRuby  |Keywords:   
-+--
 Binding to a property that is overridden by a subclass causes a
 'valueForUndefinedKey:]: this class is not key value coding-compliant for
 the key' error.

 Expected behavior: binding should call the method on the subclass.

 I've attached a project that throws this error on launch. The AppDelegate
 contains Person and Teacher instances. The nib file has a label bound to
 each. Removing the binding to teacher.name or changing the binding to a
 property that is not overridden makes the bug go away.

 I was using an early nightly for beta 0.6. I've also tested with the
 latest nightly:

 macruby_nightly-2010-03-06-1240.pkg

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


Re: [MacRuby-devel] MacRuby 0.5 vs. CG Bitmap Context

2010-03-06 Thread Brian Chapados
Hi Scott,

The problem is due to the way the macruby Pointer class handles types,
which apparently is due to an LLVM issue... The Pointer class is
defined in compiler.cpp. See this comment:

---
VALUE
rb_pointer_new(const char *type_str, void *val, size_t len)
{
// LLVM doesn't allow to get a pointer to Type::VoidTy, and for convenience
// reasons we map a pointer to void as a pointer to unsigned char.
if (*type_str == 'v') {
type_str = "C";
}
---

The good news is that you might not need to worry about it in this
case. In 10.6, you can pass NULL (use 'nil' in MacRuby) as the first
argument to CGBitmapContextCreate, as long as you don't mind letting
CoreGraphics manage the memory allocation for you:

from the docs:
---
"In Mac OS X v10.6 and later, you can pass NULL if you do not care
where the data is stored. This frees you from managing your own
memory, which reduces memory leak issues. Quartz has more flexibility
when it manages data storage for you. For example, it’s possible for
Quartz to use OpenGL for rendering if it takes care of the memory."
---

So you should be able to do something like this:

framework 'ApplicationServices'

bitmap_context = CGBitmapContextCreate(nil, 512, 512, 8, 512,
CGColorSpaceCreateDeviceGray(), KCGImageAlphaNone)

Brian

On Fri, Mar 5, 2010 at 8:34 AM, Scott Thompson  wrote:
> I'm using MacRuby to work with CoreGraphics and having some trouble with
> pointers.
> My first attempt was to create the data for a bitmap context using
> NSMutableData:
> bitmap_data = NSMutableData.alloc.initWithLength(image_data_size)
> bitmap_context = CGBitmapContextCreate(
>   bitmap_data.mutableBytes(),
>   image_width, image_height,
>   8, image_width,
>   gray_color_space, KCGImageAlphaNone)
>
> If I do this, I get an error that "expected instance of Pointer of type 'v',
> got 'C' (TypeError)"
> I gather from this that CGBitmapContextCreate was expecting a (void *) and
> got a (UInt8 *).  In C I would just type the difference away, but Ruby
> doesn't like ti.
> I tried something like:
> bitmap_data_ptr = Pointer.new_of_type('v')
> bitmap_data_ptr.assign(bitmap_data.mutableBytes())
> This didn't work very well either.  I get an error that the system can't do
> a "sizeof" of an unsized type (presumably void *)
> I also tried doing similar using CFDataRef (not much difference really).  It
> looked like:
> bitmap_data = CFDataCreateMutable(nil, image_data_size)
> CFDataSetLength(bitmap_data, image_data_size)
> bitmap_data_ptr = CFDataGetMutableBytePtr(bitmap_data)
> bitmap_context = CGBitmapContextCreate(
>   CFDataGetMutableBytePtr(bitmap_data),
>   image_width, image_height,
>   8, image_width,
>   gray_color_space, KCGImageAlphaNone)
>
> In this case, I get an error that "expected instance of Pointer, got '""'
> (NSMutableString) (TypeError)
> Evidently MacRuby sees the return value of CFDataGetMutableBytePtr as being
> a string, subsequently typecasts it as such, and goes on.
> Is there anything I can do to typecast the pointers to a type that MacRuby
> will accept?
> Scott
>
> ___
> 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 0.5 vs. CG Bitmap Context

2010-03-06 Thread Scott Thompson
> The good news is that you might not need to worry about it in this
> case. In 10.6, you can pass NULL (use 'nil' in MacRuby) as the first
> argument to CGBitmapContextCreate, as long as you don't mind letting
> CoreGraphics manage the memory allocation for you:

I am very much aware of that.  

Unfortunately, in this case, I do care about the memory allocation.  I was 
going to examine (and potentially manipulate) the memory after drawing into the 
context.  It sounds like there is no way for me to use Ruby to solve this 
problem.  I will rework my code in C and solve the problem that way.

Scott

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


Re: [MacRuby-devel] Build problems

2010-03-06 Thread Laurent Sansonetti
Sorry guys but nobody in the team is using 10.5 anymore. 

I committed a fix in r3712, please check it out again and let me know if it 
still breaks.

I also recommend to upgrade to 10.6 (Snow Leopard) if you want to do serious 
development with MacRuby.

Laurent

On Mar 1, 2010, at 5:52 PM, Michael Johnston wrote:

> I have the same problem on 10.5 -- it goes back to r3438
> 
> Before that I have the followting error:
> 
>disable optimizations when compiling re.c
> 
>git-svn-id: http://svn.macosforge.org/repository/ruby/MacRuby/tr...@3399 
> 23306eb0-4c56-4727-a40e-e92c0eb68959
> 
> 
>/usr/bin/gcc -I. -I./include -I./onig -I/usr/include/libxml2 -arch i386 
> -arch x86_64 -fno-common -pipe -O3 -g -Wall -fexceptions -Wno-parentheses 
> -Wno-deprecated-declarations -Werror -std=c99 -c signal.c -o signal.o
>signal.c:23:31: error: dispatch/dispatch.h: No such file or directory
>signal.c:24:28: error: dispatch/queue.h: No such file or directory
>signal.c:23:31: error: dispatch/dispatch.h: No such file or directory
>signal.c:24:28: error: dispatch/queue.h: No such file or directory
>lipo: can't open input file: 
> /var/folders/Qi/QiwLLAwKFdeRSa7pt-+7tk+++TI/-Tmp-//cc1znyB6.out (No such file 
> or directory)
>rake aborted!
>Command failed with status (1): [/usr/bin/gcc -I. -I./include -I./onig 
> -I/u...]
> 
>(See full trace by running task with --trace)
> 
> 
> 
> which goes back to 3337, and before that I get
> 
> /usr/bin/g++ -I/usr/local/include  -D_DEBUG -D_GNU_SOURCE 
> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2  -fno-common 
> -Woverloaded-virtual -I. -I./include -g -Wall -arch i386 -arch x86_64 
> -Wno-parentheses -Wno-deprecated-declarations -Werror -c compiler.cpp -o 
> compiler.o
> compiler.cpp: In member function 'llvm::Value* 
> RoxorCompiler::compile_dispatch_call(std::vector std::allocator >&)':
> compiler.cpp:755: error: 'class llvm::DIFactory' has no member named 
> 'InsertStopPoint'
> compiler.cpp: In member function 'llvm::Value* 
> RoxorCompiler::compile_slot_cache(long unsigned int)':
> compiler.cpp:1136: error: no matching function for call to 
> 'llvm::Instruction::clone(llvm::LLVMContext&)'
> /usr/local/include/llvm/Instruction.h:51: note: candidates are: 
> llvm::Instruction* llvm::Instruction::clone() const
> compiler.cpp: In member function 'llvm::Value* 
> RoxorCompiler::compile_landing_pad_header(const std::type_info&)':
> compiler.cpp:1877: error: 'eh_selector_i64' is not a member of 
> 'llvm::Intrinsic'
> compiler.cpp:1915: error: 'eh_typeid_for_i64' is not a member of 
> 'llvm::Intrinsic'
> compiler.cpp: In member function 'llvm::Value* 
> RoxorCompiler::compile_dispatch_call(std::vector std::allocator >&)':
> compiler.cpp:755: error: 'class llvm::DIFactory' has no member named 
> 'InsertStopPoint'
> compiler.cpp: In member function 'llvm::Value* 
> RoxorCompiler::compile_slot_cache(long unsigned int)':
> compiler.cpp:1136: error: no matching function for call to 
> 'llvm::Instruction::clone(llvm::LLVMContext&)'
> /usr/local/include/llvm/Instruction.h:51: note: candidates are: 
> llvm::Instruction* llvm::Instruction::clone() const
> compiler.cpp: In member function 'void 
> RoxorCompiler::compile_ivar_slots(llvm::Value*, 
> llvm::iplist >&, 
> llvm::ilist_iterator)':
> compiler.cpp:2980: error: no matching function for call to 
> 'llvm::Instruction::clone(llvm::LLVMContext&)'
> /usr/local/include/llvm/Instruction.h:51: note: candidates are: 
> llvm::Instruction* llvm::Instruction::clone() const
> compiler.cpp: In member function 'llvm::Value* 
> RoxorCompiler::compile_landing_pad_header(const std::type_info&)':
> compiler.cpp:1880: error: 'eh_selector_i32' is not a member of 
> 'llvm::Intrinsic'
> compiler.cpp:1918: error: 'eh_typeid_for_i32' is not a member of 
> 'llvm::Intrinsic'
> compiler.cpp: In member function 'void 
> RoxorCompiler::compile_ivar_slots(llvm::Value*, 
> llvm::iplist >&, 
> llvm::ilist_iterator)':
> compiler.cpp:2980: error: no matching function for call to 
> 'llvm::Instruction::clone(llvm::LLVMContext&)'
> /usr/local/include/llvm/Instruction.h:51: note: candidates are: 
> llvm::Instruction* llvm::Instruction::clone() const
> lipo: can't figure out the architecture type of: 
> /var/folders/Qi/QiwLLAwKFdeRSa7pt-+7tk+++TI/-Tmp-//ccJVfimM.out
> rake aborted!
> Command failed with status (1): [/usr/bin/g++ -I/usr/local/include  
> -D_DEBU...]
> 
> 
> 
> so...guess it's time to get my hackintosh on snow leopard :/
> 
> Cheerio,
> 
> Michael Johnston
> [email protected]
> 
> 
> 
> 
> On 2010-03-01, at 8:21 AM, Otto Hemmi wrote:
> 
>> I'm on OS X 10.5.8
>> 
>> I just tried to build mac ruby, llvm went fine but i get the following 
>> message on trunk.. 
>> 
>> rake
>> (in /Users/ottohemmi/playspace/macruby/MacRuby)
>> /usr/bin/ruby tool/compile_prelude.rb prelude.rb miniprelude.c.new
>> rm miniprelude.c.new
>> /usr/bin/gcc -I. -I./include -I./onig -I/usr/include/libxml2 -arch i386 
>> -arch x86_64 -fno-common -pipe

Re: [MacRuby-devel] MacRuby 0.5 vs. CG Bitmap Context

2010-03-06 Thread Laurent Sansonetti
Hi Scott,

On Mar 5, 2010, at 8:34 AM, Scott Thompson wrote:

> I'm using MacRuby to work with CoreGraphics and having some trouble with 
> pointers.
> 
> My first attempt was to create the data for a bitmap context using 
> NSMutableData:
> 
> bitmap_data = NSMutableData.alloc.initWithLength(image_data_size)
> bitmap_context = CGBitmapContextCreate(
>   bitmap_data.mutableBytes(),
>   image_width, image_height,
>   8, image_width,
>   gray_color_space, KCGImageAlphaNone)
> 
> If I do this, I get an error that "expected instance of Pointer of type 'v', 
> got 'C' (TypeError)"
> 
> I gather from this that CGBitmapContextCreate was expecting a (void *) and 
> got a (UInt8 *).  In C I would just type the difference away, but Ruby 
> doesn't like ti.
> 
> I tried something like:
> 
> bitmap_data_ptr = Pointer.new_of_type('v')
> bitmap_data_ptr.assign(bitmap_data.mutableBytes())
> 
> This didn't work very well either.  I get an error that the system can't do a 
> "sizeof" of an unsized type (presumably void *)
> 
> I also tried doing similar using CFDataRef (not much difference really).  It 
> looked like:
> 
> bitmap_data = CFDataCreateMutable(nil, image_data_size)
> CFDataSetLength(bitmap_data, image_data_size)
> bitmap_data_ptr = CFDataGetMutableBytePtr(bitmap_data)
> bitmap_context = CGBitmapContextCreate(
>   CFDataGetMutableBytePtr(bitmap_data),
>   image_width, image_height,
>   8, image_width,
>   gray_color_space, KCGImageAlphaNone)
> 
> In this case, I get an error that "expected instance of Pointer, got '""' 
> (NSMutableString) (TypeError)
> 
> Evidently MacRuby sees the return value of CFDataGetMutableBytePtr as being a 
> string, subsequently typecasts it as such, and goes on.
> 
> Is there anything I can do to typecast the pointers to a type that MacRuby 
> will accept?

Unfortunately, the Pointer class currently will not allow you to cast types :( 
If you file a bug in Trac we will add this functionality in the next release. 
Patches are also welcome :)

In the meantime I would recommend to write this in Objective-C and call it from 
MacRuby.

Sorry,
Laurent___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel