Fujimoto Hisa
hisa****@fobj*****
Wed Feb 28 09:14:06 JST 2007
thanks! the apps worked fine. -- hisa On 2007/02/28, at 7:09, Laurent Sansonetti wrote: > Fixed in 1602. > > On Feb 27, 2007, at 7:24 PM, Laurent Sansonetti wrote: > >> I managed to track the problem to a specific revision change (post >> 1585), now fixing... >> >> Laurent >> >> On Feb 23, 2007, at 1:58 PM, Laurent Sansonetti wrote: >> >>> I can reproduce, arigato! I'm off for a few days but will try to >>> investigate this the week-end if I can. >>> >>> Laurent >>> >>> On Feb 23, 2007, at 8:16 AM, Fujimoto Hisa wrote: >>> >>> >>>> Hi Laurent >>> >>>> >>> >>>> Two samples, CIBevelSample and CIMicroPaint, down with the current >>> >>>> (1589). >>> >>>> These seemed to work until a few days ago. I can't find out the >>>> cause >>> >>>> yet, and appended the snippet of the stack trace. >>> >>>> >>> >>>> about CIMicroPaint, it down at the line 134 in sample/ >>>> SampleCIView.rb >>> >>>> >>> >>>> @context.drawImage_atPoint_fromRect(@image, rr.origin, rr) >>> >>>> >>> >>>> -- >>> >>>> hisa >>> >>>> >>> >>>> >>> >>>> # snippet of >>> >>>> Exception: EXC_BAD_ACCESS (0x0001) >>> >>>> Codes: KERN_INVALID_ADDRESS (0x0001) at 0x72662e71 >>> >>>> >>> >>>> Thread 0 Crashed: >>> >>>> 0 libSystem.B.dylib 0x90000f88 >>>> pthread_mutex_lock >>> >>>> + 17 >>> >>>> 1 com.apple.opengl 0x931c059e >>> >>>> CGLGetVirtualScreen + 172 >>> >>>> 2 com.apple.QuartzCore 0x93ed41bb >>> >>>> fe_cgl_context_screen >>> >>>> + 32 >>> >>>> 3 com.apple.QuartzCore 0x93ebdac0 - >>> >>>> [CIOpenGLContextImpl >>> >>>> updateContext] + 61 >>> >>>> 4 com.apple.QuartzCore 0x93ebd9b6 - >>> >>>> [CIOpenGLContextImpl >>> >>>> render:] + 196 >>> >>>> 5 com.apple.QuartzCore 0x93ed6377 -[CIContext >>> >>>> drawImage:inRect:fromRect:] + 1437 >>> >>>> 6 com.apple.QuartzCore 0x93ed854a -[CIContext >>> >>>> drawImage:atPoint:fromRect:] + 121 >>> >>>> 7 com.apple.rubycocoa 0x0003229d ffi_call_SYSV >>>> + 29 >>> >>>> 8 com.apple.rubycocoa 0x0003223e ffi_call + 98 >>> >>>> 9 com.apple.rubycocoa 0x0002f917 rb_ffi_dispatch + >>> >>>> 579 >>> >>>> 10 com.apple.rubycocoa 0x000211ee objcptr_cptr + >>>> 1465 >>> >>>> 11 com.apple.rubycocoa 0x000219c4 objcptr_cptr + >>>> 3471 >>> >>>> 12 libruby.1.dylib 0x96092259 >>> >>>> rb_with_disable_interrupt + 450 >>> >>>> 13 libruby.1.dylib 0x9609a973 Init_eval + 17638 >>> >>>> 14 libruby.1.dylib 0x9609b1d8 Init_eval + 19787 >>> >>>> 15 libruby.1.dylib 0x960987a1 Init_eval + 8980 >>> >>>> 16 libruby.1.dylib 0x96099281 Init_eval + 11764 >>> >>>> 17 libruby.1.dylib 0x9609ae6b Init_eval + 18910 >>> >>>> 18 libruby.1.dylib 0x9609b1d8 Init_eval + 19787 >>> >>>> 19 libruby.1.dylib 0x9609e796 rb_thread_wait_fd >>> >>>> + 938 >>> >>>> >>> >>>> >>> >>>> # from CIMicroPaint.crash.log >>> >>>> Exception: EXC_BAD_ACCESS (0x0001) >>> >>>> Codes: KERN_INVALID_ADDRESS (0x0001) at 0x439c0010 >>> >>>> >>> >>>> Thread 0 Crashed: >>> >>>> 0 libSystem.B.dylib 0x90000f88 >>>> pthread_mutex_lock >>> >>>> + 17 >>> >>>> 1 com.apple.opengl 0x931c059e >>> >>>> CGLGetVirtualScreen + 172 >>> >>>> 2 com.apple.QuartzCore 0x93ed41bb >>> >>>> fe_cgl_context_screen >>> >>>> + 32 >>> >>>> 3 com.apple.QuartzCore 0x93ebdac0 - >>> >>>> [CIOpenGLContextImpl >>> >>>> updateContext] + 61 >>> >>>> 4 com.apple.QuartzCore 0x93ebd9b6 - >>> >>>> [CIOpenGLContextImpl >>> >>>> render:] + 196 >>> >>>> 5 com.apple.QuartzCore 0x93ed6377 -[CIContext >>> >>>> drawImage:inRect:fromRect:] + 1437 >>> >>>> 6 com.apple.QuartzCore 0x93ed854a -[CIContext >>> >>>> drawImage:atPoint:fromRect:] + 121 >>> >>>> 7 com.apple.rubycocoa 0x0003229d ffi_call_SYSV >>>> + 29 >>> >>>> 8 com.apple.rubycocoa 0x0003223e ffi_call + 98 >>> >>>> 9 com.apple.rubycocoa 0x0002f917 rb_ffi_dispatch + >>> >>>> 579 >>> >>>> 10 com.apple.rubycocoa 0x000211ee objcptr_cptr + >>>> 1465 >>> >>>> 11 com.apple.rubycocoa 0x000219c4 objcptr_cptr + >>>> 3471 >>> >>>> 12 libruby.1.dylib 0x96092259 >>> >>>> rb_with_disable_interrupt + 450 >>> >>>> 13 libruby.1.dylib 0x9609a973 Init_eval + 17638 >>> >>>> >>> >>>> >>> >>>> On 2007/02/23, at 3:45, Laurent Sansonetti wrote: >>> >>>> >>> >>>> >>> >>>> >>>>> Hi guys, >>> >>>> >>> >>>> >>>>> >>> >>>> >>> >>>> >>>>> I added some better support for functions/methods dealing with C- >>> >>>> >>> >>>> >>>>> array >>> >>>> >>> >>>> >>>>> like arguments and/or return value, whose length isn't fixed and >>> >>>> >>> >>>> >>>>> depend on the context. >>> >>>> >>> >>>> >>>>> >>> >>>> >>> >>>> >>>>> Examples: >>> >>>> >>> >>>> >>>>> >>> >>>> >>> >>>> >>>>> CGColorRef CGColorCreate ( CGColorSpaceRef colorspace, const float >>> >>>> >>> >>>> >>>>> components[] ); >>> >>>> >>> >>>> >>>>> // 'components' length depends on the colorspace (it's the number >>>>> of >>> >>>> >>> >>>> >>>>> colors + 1) >>> >>>> >>> >>>> >>>>> >>> >>>> >>> >>>> >>>>> const float *CGColorGetComponents ( CGColorRef color ); >>> >>>> >>> >>>> >>>>> // the return value also depends on the chosen colorspace >>> >>>> >>> >>>> >>>>> >>> >>>> >>> >>>> >>>>> Before it was necessary to deal with Array#pack, String#unpack and >>> >>>> >>> >>>> >>>>> OSX::ObjCPtr. >>> >>>> >>> >>>> >>>>> >>> >>>> >>> >>>> >>>>> Now you can also write: >>> >>>> >>> >>>> >>>>> >>> >>>> >>> >>>> >>>>> components = [0.1, 0.5, 0.9, 0] >>> >>>> >>> >>>> >>>>> color = CGColorCreate(CGColorSpaceCreateDeviceRGB(), components) >>> >>>> >>> >>>> >>>>> # (1) >>> >>>> >>> >>>> >>>>> components2 = CGColorGetComponents(color) # (2) >>> >>>> >>> >>>> >>>>> p components2[0] >>> >>>> >>> >>>> >>>>> >>> >>>> >>> >>>> >>>>> Technically, >>> >>>> >>> >>>> >>>>> >>> >>>> >>> >>>> >>>>> (1) RubyCocoa is now able to convert a Ruby array to this kind of >>> >>>> >>> >>>> >>>>> _C_PTR >>> >>>> >>> >>>> >>>>> (2) RubyCocoa has no way to know the size of the returned >>>>> array, so >>> >>>> >>> >>>> >>>>> it >>> >>>> >>> >>>> >>>>> still returns an OSX::ObjCPtr object. But it's now possible to >>>>> call >>> >>>> >>> >>>> >>>>> OSX::ObjCPtr#[] to retrieve arbitrary elements from the pointer. >>> >>>> >>> >>>> >>>>> >>> >>>> >>> >>>> >>>>> Of course, the user needs to be very careful when writing such >>>>> code. >>> >>>> >>> >>>> >>>>> Passing a array of non-expected length and/or trying to access an >>> >>>> >>> >>>> >>>>> element at a non-expected index can crash the current application. >>> >>>> >>> >>>> >>>>> But >>> >>>> >>> >>>> >>>>> this kind of problems exist in C/ObjC too, and also with the >>> >>>> >>>>> previous >>> >>>> >>> >>>> >>>>> way (using the packing functions). >>> >>>> >>> >>>> >>>>> >>> >>>> >>> >>>> >>>>> Laurent >>> >>>> >>> >>>> >>>>> _______________________________________________ >>> >>>> >>> >>>> >>>>> Rubycocoa-devel mailing list >>> >>>> >>> >>>> >>>>> Rubyc****@lists***** >>> >>>> >>> >>>> >>>>> http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel >>> >>>> >>> >>>> _______________________________________________ >>> >>>> Rubycocoa-devel mailing list >>> >>>> Rubyc****@lists***** >>> >>>> http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel >>> >>> _______________________________________________ >>> Rubycocoa-devel mailing list >>> Rubyc****@lists***** >>> http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel >> >> _______________________________________________ >> Rubycocoa-devel mailing list >> Rubyc****@lists***** >> http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel > > _______________________________________________ > Rubycocoa-devel mailing list > Rubyc****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel
