Menu
▾
▴
rubycocoa-talk — talking about RubyCocoa
You can subscribe to this list here.
| 2002 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(3) |
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(1) |
Feb
(11) |
Mar
(9) |
Apr
(1) |
May
(5) |
Jun
(5) |
Jul
(4) |
Aug
(3) |
Sep
(15) |
Oct
(8) |
Nov
(9) |
Dec
(11) |
| 2004 |
Jan
(5) |
Feb
(2) |
Mar
(1) |
Apr
(3) |
May
(6) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
|
Dec
(3) |
| 2005 |
Jan
(1) |
Feb
(7) |
Mar
(6) |
Apr
(36) |
May
(20) |
Jun
(42) |
Jul
(21) |
Aug
(12) |
Sep
(56) |
Oct
(5) |
Nov
(55) |
Dec
(53) |
| 2006 |
Jan
(43) |
Feb
(83) |
Mar
(98) |
Apr
(42) |
May
(68) |
Jun
(55) |
Jul
(50) |
Aug
(104) |
Sep
(13) |
Oct
(70) |
Nov
(37) |
Dec
(42) |
| 2007 |
Jan
(56) |
Feb
(18) |
Mar
(43) |
Apr
(80) |
May
(65) |
Jun
(149) |
Jul
(103) |
Aug
(71) |
Sep
(62) |
Oct
(67) |
Nov
(72) |
Dec
(63) |
| 2008 |
Jan
(64) |
Feb
(63) |
Mar
(31) |
Apr
(42) |
May
(71) |
Jun
(62) |
Jul
(37) |
Aug
(25) |
Sep
(5) |
Oct
(2) |
Nov
(7) |
Dec
(14) |
| 2009 |
Jan
(20) |
Feb
(15) |
Mar
(19) |
Apr
(8) |
May
(7) |
Jun
|
Jul
(37) |
Aug
(12) |
Sep
(19) |
Oct
(5) |
Nov
(1) |
Dec
(4) |
| 2010 |
Jan
(5) |
Feb
(24) |
Mar
(16) |
Apr
(9) |
May
(4) |
Jun
|
Jul
|
Aug
(6) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(5) |
Dec
|
| 2016 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Eloy D. <elo...@gm...> - 2009-07-25 04:38:19
|
Yay! Great work indeed Kimura-san! @Mikiya-san As far as I know it won`t be included in the initial release, hopefully in 10.6.1 which should probably not be too long after the initial release. Eloy On Sat, Jul 25, 2009 at 9:39 AM, Mikiya Okuno<mik...@gm...> wrote: > Hi Kimura-san, > > Great! Thank you for your fabulous work :) > > By the way, will the new version be shipped with Snow Leopard? > > Kind regards, > -- > Mikiya Okuno > > 2009/7/25 kimura wataru <kimuraw@i.nifty.jp>: >> Hi, >> >> I am honored to announce the immediate release of RubyCocoa 1.0.0. >> >> RubyCocoa is a Mac OS X framework that allows Cocoa programming in the >> object-oriented scripting language Ruby. In other words, it is a >> bridge that let you access Objective-C objects from Ruby, and vice-versa. >> >> You can learn more about RubyCocoa on our website: >> >> http://rubycocoa.sf.net >> >> A source tarball as well as binary installers for Mac OS X 10.4 and >> 10.5 are provided. >> >> This is mostly a bugs fix release, addressing a few critical issues. A >> few enhancements are nevertheless available as well. All users are >> encouraged to upgrade, and report us feedback. >> >> Mac OS X 10.5, Leopard, is as you can see supported by this release. >> Installing this release using the binary installer or manually with >> the default build parameters won't override the system version of >> RubyCocoa that ships with Leopard, it will go in /Library while the >> system version is in /System. >> >> (Very recently, the system version of RubyCocoa in Mac OS X 10.5 was >> updated to 0.13.2, via software update.) >> >> The release notes are following. Enjoy! >> >> KIMURA Wataru >> >> bug fixes >> - imcompatible NSString#split >> - cannot handle KVC/KVO autonotify >> - KVO willChangeValueForKey/didChangeValueForKey was invoked twice >> - NSBundle.bundleForClass: crashes on ruby uninitialized thread >> - libffi: ffi_call( return value buffer too small) >> - GraphicsContext.graphicsContextWithGraphicsPort_flipped crashes >> - DLOG macro: format string should be literal >> - avoid override Objective-C methods with syntax sugar methods >> - crash with "[BUG] object allocation during garbage collection phase" on 10.5.7 >> >> >> enhancements >> - ruby 1.8.7 ready >> - crash with "[BUG] object allocation during garbage collection phase" >> - infinit loop of NSArray#count and NSDictionary#count >> - behavior of basic Ruby classes' methods was changed in 1.8.7 >> - new sample PassengerPane >> - better build settings for 10.5 >> - support formal protocols (10.5 or later) >> - rake install task: check finish of building >> - rake package task: use concrete configure settings from package/config/ >> >> >> misc >> - change install destination of Xcode templates (enable templates on Xcode3.1) >> - add document for OSX.require_framework >> - fix failure of a test, test_loadlibs() >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Rubycocoa-talk mailing list >> Rub...@li... >> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > |
|
From: Mikiya O. <mik...@gm...> - 2009-07-25 00:39:55
|
Hi Kimura-san, Great! Thank you for your fabulous work :) By the way, will the new version be shipped with Snow Leopard? Kind regards, -- Mikiya Okuno 2009/7/25 kimura wataru <kimuraw@i.nifty.jp>: > Hi, > > I am honored to announce the immediate release of RubyCocoa 1.0.0. > > RubyCocoa is a Mac OS X framework that allows Cocoa programming in the > object-oriented scripting language Ruby. In other words, it is a > bridge that let you access Objective-C objects from Ruby, and vice-versa. > > You can learn more about RubyCocoa on our website: > > http://rubycocoa.sf.net > > A source tarball as well as binary installers for Mac OS X 10.4 and > 10.5 are provided. > > This is mostly a bugs fix release, addressing a few critical issues. A > few enhancements are nevertheless available as well. All users are > encouraged to upgrade, and report us feedback. > > Mac OS X 10.5, Leopard, is as you can see supported by this release. > Installing this release using the binary installer or manually with > the default build parameters won't override the system version of > RubyCocoa that ships with Leopard, it will go in /Library while the > system version is in /System. > > (Very recently, the system version of RubyCocoa in Mac OS X 10.5 was > updated to 0.13.2, via software update.) > > The release notes are following. Enjoy! > > KIMURA Wataru > > bug fixes > - imcompatible NSString#split > - cannot handle KVC/KVO autonotify > - KVO willChangeValueForKey/didChangeValueForKey was invoked twice > - NSBundle.bundleForClass: crashes on ruby uninitialized thread > - libffi: ffi_call( return value buffer too small) > - GraphicsContext.graphicsContextWithGraphicsPort_flipped crashes > - DLOG macro: format string should be literal > - avoid override Objective-C methods with syntax sugar methods > - crash with "[BUG] object allocation during garbage collection phase" on 10.5.7 > > > enhancements > - ruby 1.8.7 ready > - crash with "[BUG] object allocation during garbage collection phase" > - infinit loop of NSArray#count and NSDictionary#count > - behavior of basic Ruby classes' methods was changed in 1.8.7 > - new sample PassengerPane > - better build settings for 10.5 > - support formal protocols (10.5 or later) > - rake install task: check finish of building > - rake package task: use concrete configure settings from package/config/ > > > misc > - change install destination of Xcode templates (enable templates on Xcode3.1) > - add document for OSX.require_framework > - fix failure of a test, test_loadlibs() > > > ------------------------------------------------------------------------------ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > |
|
From: kimura w. <kimuraw@i.nifty.jp> - 2009-07-25 00:16:29
|
Hi, I am honored to announce the immediate release of RubyCocoa 1.0.0. RubyCocoa is a Mac OS X framework that allows Cocoa programming in the object-oriented scripting language Ruby. In other words, it is a bridge that let you access Objective-C objects from Ruby, and vice-versa. You can learn more about RubyCocoa on our website: http://rubycocoa.sf.net A source tarball as well as binary installers for Mac OS X 10.4 and 10.5 are provided. This is mostly a bugs fix release, addressing a few critical issues. A few enhancements are nevertheless available as well. All users are encouraged to upgrade, and report us feedback. Mac OS X 10.5, Leopard, is as you can see supported by this release. Installing this release using the binary installer or manually with the default build parameters won't override the system version of RubyCocoa that ships with Leopard, it will go in /Library while the system version is in /System. (Very recently, the system version of RubyCocoa in Mac OS X 10.5 was updated to 0.13.2, via software update.) The release notes are following. Enjoy! KIMURA Wataru bug fixes - imcompatible NSString#split - cannot handle KVC/KVO autonotify - KVO willChangeValueForKey/didChangeValueForKey was invoked twice - NSBundle.bundleForClass: crashes on ruby uninitialized thread - libffi: ffi_call( return value buffer too small) - GraphicsContext.graphicsContextWithGraphicsPort_flipped crashes - DLOG macro: format string should be literal - avoid override Objective-C methods with syntax sugar methods - crash with "[BUG] object allocation during garbage collection phase" on 10.5.7 enhancements - ruby 1.8.7 ready - crash with "[BUG] object allocation during garbage collection phase" - infinit loop of NSArray#count and NSDictionary#count - behavior of basic Ruby classes' methods was changed in 1.8.7 - new sample PassengerPane - better build settings for 10.5 - support formal protocols (10.5 or later) - rake install task: check finish of building - rake package task: use concrete configure settings from package/config/ misc - change install destination of Xcode templates (enable templates on Xcode3.1) - add document for OSX.require_framework - fix failure of a test, test_loadlibs() |
|
From: Duncan M. <du...@on...> - 2009-07-22 07:58:41
|
Just a heads up for posterity. AT&T are shipping a 3G modem card that
overrides the installed version of RubyCocoa. With VelOCRaptor the
symptoms are an exception thrown when I attempt to call new on an
NSClass
/Library/Frameworks/RubyCocoa.framework/Resources/ruby/osx/objc/
oc_import.rb:251:in `new': use 'alloc.initXXX' to instantiate Cocoa
Object (RuntimeError)
The frameworks they are installing are
RubyCocoa:
Version: 0.12.0
Last Modified: 6/29/09 11:01 PM
Get Info String: RubyCocoa 0.12.0 Copyright (c) 2002 FUJIMOTO
Hisakuni.
Location: /Library/Frameworks/RubyCocoa.framework
Private: No
NMGsmKit:
Version: 0.2.0
Last Modified: 6/29/09 11:01 PM
Location: /Library/Frameworks/NMGsmKit.framework
Private: No
NML2NManager:
Version: 0.3.0
Last Modified: 6/29/09 11:01 PM
Location: /Library/Frameworks/NML2NManager.framework
Private: No
NMNetCore:
Version: 0.6.0
Last Modified: 6/29/09 11:01 PM
Location: /Library/Frameworks/NMNetCore.framework
Private: No
NMNetWorker:
Version: 0.2.0
Last Modified: 6/29/09 11:01 PM
Location: /Library/Frameworks/NMNetWorker.framework
Private: No
NMRegistrationCore:
Version: 0.3.0
Last Modified: 6/29/09 11:01 PM
Location: /Library/Frameworks/NMRegistrationCore.framework
Private: No
On Kimura Wataru's excellent advice, I am looking at setting
DYLD_FRAMEWORK_PATH or maybe DYLD_FALLBACK_FRAMEWORK_PATH to solve
this problem, but as I can't reproduce it here yet, I am unable to
report whether or not this works.
Duncan McGregor
www.velOCRaptor.com
Simple Affordable Mac OCR
|
|
From: Duncan M. <du...@on...> - 2009-07-21 23:46:38
|
On 22 Jul 2009, at 00:01, kimura wataru wrote: > Hi, > > Add LSEnvironment into your application's Info.plist and > set DYLD_FRAMEWORK_PATH to /System/Library/Frameworks. > like this; > > <key>LSEnvironment</key> > <dict> > <key>DYLD_FRAMEWORK_PATH</key> > <string>/System/Library/Frameworks</string> > </dict> > > This means your app prefers frameworks under /System/Library/ > Frameworks > rather than under other locations. > > for detail, see the below references. > > http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/EnvironmentVars.html > http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html > http://developer.apple.com/documentation/Darwin/Reference/Manpages/man1/dyld.1.html Thank you very much. A slight problem is that I am using RubyCocoa directly from a .rb script not an app bundle and so don't have an Info.plist, but I'm sure that I can set the equivalent environment variables before I invoke the script. Thanks again Duncan |
|
From: kimura w. <kimuraw@i.nifty.jp> - 2009-07-21 23:14:09
|
Hi,
Add LSEnvironment into your application's Info.plist and
set DYLD_FRAMEWORK_PATH to /System/Library/Frameworks.
like this;
<key>LSEnvironment</key>
<dict>
<key>DYLD_FRAMEWORK_PATH</key>
<string>/System/Library/Frameworks</string>
</dict>
This means your app prefers frameworks under /System/Library/Frameworks
rather than under other locations.
for detail, see the below references.
http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/EnvironmentVars.html
http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html
http://developer.apple.com/documentation/Darwin/Reference/Manpages/man1/dyld.1.html
On Tue, 21 Jul 2009 11:18:20 +0100, Duncan McGregor wrote:
> My app VelOCRaptor depends on RubyCocoa, which is shipped with Leopard
> as a framework version 0.13.1. I don't support Tiger, so have been
> happy to assume that the framework is installed in /System/Library/
> Frameworks
>
> Yesterday 2 people found an issue that turns out to be due to another
> piece of software (for some 3G card AFAICT) installing an older
> version of the RubyCocoa framework in /Library/Frameworks
>
> Is there any way to specify which version of the framework should be
> loaded when I require 'osx/cocoa'?
>
> Thanks in anticipation
>
> Duncan McGregor
>
--
kimura wataru
|
|
From: kimura w. <ki...@us...> - 2009-07-21 23:09:59
|
Hi,
Add LSEnvironment into your application's Info.plist and
set DYLD_FRAMEWORK_PATH to /System/Library/Frameworks.
like this;
<key>LSEnvironment</key>
<dict>
<key>DYLD_FRAMEWORK_PATH</key>
<string>/System/Library/Frameworks</string>
</dict>
This means your app prefers frameworks under /System/Library/Frameworks
rather than under other locations.
for detail, see the below references.
http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/EnvironmentVars.html
http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html
http://developer.apple.com/documentation/Darwin/Reference/Manpages/man1/dyld.1.html
On Tue, 21 Jul 2009 11:18:20 +0100, Duncan McGregor wrote:
> My app VelOCRaptor depends on RubyCocoa, which is shipped with Leopard
> as a framework version 0.13.1. I don't support Tiger, so have been
> happy to assume that the framework is installed in /System/Library/
> Frameworks
>
> Yesterday 2 people found an issue that turns out to be due to another
> piece of software (for some 3G card AFAICT) installing an older
> version of the RubyCocoa framework in /Library/Frameworks
>
> Is there any way to specify which version of the framework should be
> loaded when I require 'osx/cocoa'?
>
> Thanks in anticipation
>
> Duncan McGregor
>
--
kimura wataru
|
|
From: Duncan M. <du...@on...> - 2009-07-21 10:40:03
|
My app VelOCRaptor depends on RubyCocoa, which is shipped with Leopard as a framework version 0.13.1. I don't support Tiger, so have been happy to assume that the framework is installed in /System/Library/ Frameworks Yesterday 2 people found an issue that turns out to be due to another piece of software (for some 3G card AFAICT) installing an older version of the RubyCocoa framework in /Library/Frameworks Is there any way to specify which version of the framework should be loaded when I require 'osx/cocoa'? Thanks in anticipation Duncan McGregor |
|
From: Duncan M. <du...@on...> - 2009-07-08 08:54:02
|
On 7 Jul 2009, at 15:20, Scott Thompson wrote: > Great! Now that you've got that sorted out, and at the risk of > being booted off the __ruby__cocoa list, let me offer a suggestion > that may help. > > Rubycocoa is a very nice tool, but if you want to interact with > Quartz 2D from a scripting environment, I might suggest using Python > if you can stomach the language. Apple provides direct and > integrated support for Quartz 2D from Python through a dedicated and > supported API. See, for example: > > http://developer.apple.com/graphicsimaging/pythonandquartz.html > > and > > http://developer.apple.com/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_python/dq_python.html > > It makes me sad :'-( that the same interface is not available > through Ruby but in this particular case, with lots of Quartz 2D > work to be done, if you can force yourself to learn "enough Python" > it may give you a better, more battle-tested interface. It doesn't sound like there's anyone else around to kick us out! I'm using RubyCocoa as glue inside VelOCRaptor, my Mac OCR app. The GUI is pure ObjC, but all the interfacing to the OCR engine is done by shelling to a Ruby command-line app that reads the input files and writes the output PDF. Ruby was a fantastic choice for parsing the OCR output and gluing it all together, and as I started talking to Cocoa to read PDFs, convert image formats, and write PDF files, RubyCocoa made sense. I had seen the Python Quartz interface, and I've nothing against Python, but as I start from Ruby it would mean another thunking, and frankly I'm only using the CGImage stuff because I can't get NSGraphicsContext graphicsContextWithGraphicsPort:flipped: working in order to use NSImage drawInRect: I'm afraid that given my problems calling some methods at all and other problems with memory leaks that I just don't seem to be able to plug (I need to loop over hundreds of 300 DPI A4 images) I am retreating back into loading native ObjC from a code bundle for those critical bits. I can see that MacRuby is getting the traction at the moment, and it is probably a better way to go, but as a recently released commercial product with a bug to fix the path of least resistance right now is moving code into ObjC, as at least that way I can ask for mainstream support (present company excepted). As the author of the Rococoa Java/Cocoa bridge I know how hard this stuff is to get right, and that there are some memory management issues that Apple just don't give us the tools to solve. Perhaps RubyCocoa just can't meet the brief. Cheers Duncan |
|
From: Scott T. <ea...@ma...> - 2009-07-07 19:29:52
|
>I really appreciate you sticking around once again Scott. Before my >original post I had tried a pool, and I had tried CFRelease, and I had >tried GC - but it turns out that I hadn't tried a pool _and_ CFRelease >_and_ GC in the same loop. It works! Great! Now that you've got that sorted out, and at the risk of being booted off the __ruby__cocoa list, let me offer a suggestion that may help. Rubycocoa is a very nice tool, but if you want to interact with Quartz 2D from a scripting environment, I might suggest using Python if you can stomach the language. Apple provides direct and integrated support for Quartz 2D from Python through a dedicated and supported API. See, for example: http://developer.apple.com/graphicsimaging/pythonandquartz.html and http://developer.apple.com/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_python/dq_python.html It makes me sad :'-( that the same interface is not available through Ruby but in this particular case, with lots of Quartz 2D work to be done, if you can force yourself to learn "enough Python" it may give you a better, more battle-tested interface. Scott |
|
From: Duncan M. <du...@on...> - 2009-07-07 10:09:18
|
On 7 Jul 2009, at 00:01, Scott Thompson wrote:
> Ok. If it's not the garbage collector, how about an autorelease
> pool. Surround your code in the loop with a local autorelease pool
> and see if there might be some objective c objects hanging around
> longer that you want them to.
I really appreciate you sticking around once again Scott. Before my
original post I had tried a pool, and I had tried CFRelease, and I had
tried GC - but it turns out that I hadn't tried a pool _and_ CFRelease
_and_ GC in the same loop. It works!
I can't claim to understand why this works (or why more sensible
solutions don't), but I post it here for posterity.
def test_dispose_CGImageSource
# All of draining the pool, releasing the image and the GC are
required if this is not to leak
1.upto(10000) do |i|
p i
pool = NSAutoreleasePool.new
imageSource =
CGImageSourceCreateWithURL(NSURL.fileURLWithPath('testdata/pot pourri/
blood.jpg'), nil)
image = CGImageSourceCreateImageAtIndex(imageSource, 0, nil)
CFRelease image
# CFRelease imageSource - can't as will segfault
pool.drain
ObjectSpace.garbage_collect
end
end
I suspect that the explicit GC is required here for whatever reason it
is required in my other post re disposing NSImage - in a hard
RubyCocoa loop the GC doesn't seem to be triggered.
Thanks again for keeping me believing that there is a way!
Duncan
|
|
From: Duncan M. <du...@on...> - 2009-07-06 23:10:49
|
Sorry, yet more woes from me.
I've pretty much given up being able to write PDF directly from
RubyCocoa without leaking badly (CGImageSourceRefs, can't live with
'em, can't dispose of 'em), and as my customers are passing 200 pages
of 300 DPI images for me to write to a PDF, this is a big problem.
So I've moved the PDF rendering into an Objective-C class, and then
load and use that class from my RubyCocoa class, passing in
NSImageRepresentations. But I still leak. In the end it boils down to
the following test
#!/usr/bin/env ruby
require 'test/unit'
require 'osx/cocoa'
include OSX
OSX::NSApplication.sharedApplication
NSBundle.bundleWithPath('build/Debug/VelOCRaptorShared.bundle').load
class QuartzPDFWriterTest < Test::Unit::TestCase
def test_NSImage
1.upto(10000) do |i|
p i
image = NSImage.alloc.initWithContentsOfFile 'testdata/pot pourri/
blood.jpg'
#ObjectSpace.garbage_collect
end
end
end
If I don't garbage collect, this code will run from the console until
the process has consumed all available memory and started sucking
disk. If I un-comment the garbage_collect, it sits happily at 30MB or
so of real memory.
As a Java guy I expected not to have to second-guess when GC would be
a good idea, but here it seems that Ruby just doesn't try to GC in the
hard loop. Is this due to the green threads, or am I missing something
fundamental here? When does Ruby start a GC in normal code?
Cheers
Duncan
|
|
From: Scott T. <ea...@ma...> - 2009-07-06 23:01:28
|
> > > > does not crash but runs out of memory as fast as it does without the > GC (well, actually much slower, as the GC is slow, but at the same > number of iterations). Ok. If it's not the garbage collector, how about an autorelease pool. Surround your code in the loop with a local autorelease pool and see if there might be some objective c objects hanging around longer that you want them to. |
|
From: Duncan M. <du...@on...> - 2009-07-06 20:21:20
|
On 6 Jul 2009, at 20:22, Scott Thompson wrote:
>> CFRelease imageSource results in a segfault or bus error. For low
>> iteration counts this happens after the test has finished, increasing
>> the count makes it happen during the loop, suggesting a problem
>> during
>> garbage collection I think.
>>
>> If I don't CFRelease imageSource then I run out of memory to load any
>> more images after about 4000 iterations with my test file.
> It does sound like a problems somewhere in the garbage collector.
> It seems like the garbage collector is trying to keep the reference
> that rightfully belongs to you.
>
> Have you tried taking out your calls to CFRelease and forcing the
> garbage collector to run every iteration through the loop as a test
> (say by calling GC.garbage_collect). Seems a bit extreme, but it
> would let you know if the ruby proxy wants to "own" your CG objects
> for you.
1.upto(10000) do |i|
imageSource =
CGImageSourceCreateWithURL(NSURL.fileURLWithPath('testdata/pot pourri/
blood.jpg'), nil)
image = CGImageSourceCreateImageAtIndex(imageSource, 0, nil)
#CFRelease image
#CFRelease imageSource
ObjectSpace.garbage_collect
end
does not crash but runs out of memory as fast as it does without the
GC (well, actually much slower, as the GC is slow, but at the same
number of iterations).
Am I right in thinking that RubyCococa is now effectively an Apple
project, and so comes with the usual high level of support ;-?
D
|
|
From: Scott T. <ea...@ma...> - 2009-07-06 19:23:14
|
>CFRelease imageSource results in a segfault or bus error. For low >iteration counts this happens after the test has finished, increasing >the count makes it happen during the loop, suggesting a problem during >garbage collection I think. > >If I don't CFRelease imageSource then I run out of memory to load any >more images after about 4000 iterations with my test file. > >Does anyone have any ideas please? It does sound like a problems somewhere in the garbage collector. It seems like the garbage collector is trying to keep the reference that rightfully belongs to you. Have you tried taking out your calls to CFRelease and forcing the garbage collector to run every iteration through the loop as a test (say by calling GC.garbage_collect). Seems a bit extreme, but it would let you know if the ruby proxy wants to "own" your CG objects for you. |
|
From: Duncan M. <du...@on...> - 2009-07-06 17:05:21
|
On 6 Jul 2009, at 16:33, Patrick Geiller wrote:
>> Sorry to repost, but this has become a real blocker for me - I
>> thought
>> I'd try one last time before giving up and re-coding in ObjC.
>>
>> I can't persuade RubyCocoa to CFRelease a CGImageSourceRef without a
>> bus error - as a result my PDF writing code is leaking like a sieve.
>
> Try adding some GC code, keeping references and nulling them after
> release.
>
> GC.disable
> imageSource =
> CGImageSourceCreateWithURL(NSURL.fileURLWithPath('testdata/pot
> pourri/blood.jpg'), nil)
> image = CGImageSourceCreateImageAtIndex(imageSource, 0, nil)
> CFRelease image
> CFRelease imageSource
> image = imageSource = nil
> GC.enable
> GC.start
>
> Try that for each iteration, and if it works you might want to do it
> only each 10 or 100 iterations.
I had played around with GC just after sending the mail. If I use the
code as you've written, it segfaults after 2 iterations, without
messing with GC, 726 iterations, or on app shutdown, whichever is
sooner.
Looks to be a classic double-free, but with the irritating problem of
a large memory leak if I leave it alone.
Does anyone know where I can report this as a bug. Is it Apple,
SourceForge?
Cheers
Duncan |
|
From: Patrick G. <par...@gm...> - 2009-07-06 16:03:32
|
> Sorry to repost, but this has become a real blocker for me - I thought
> I'd try one last time before giving up and re-coding in ObjC.
>
> I can't persuade RubyCocoa to CFRelease a CGImageSourceRef without a
> bus error - as a result my PDF writing code is leaking like a sieve.
Try adding some GC code, keeping references and nulling them after
release.
GC.disable
imageSource =
CGImageSourceCreateWithURL(NSURL.fileURLWithPath('testdata/pot pourri/
blood.jpg'), nil)
image = CGImageSourceCreateImageAtIndex(imageSource, 0, nil)
CFRelease image
CFRelease imageSource
image = imageSource = nil
GC.enable
GC.start
Try that for each iteration, and if it works you might want to do it
only each 10 or 100 iterations.
On another note, I had a GC problem with a QCView being collected
early even though it was retained by its parent view. Adding it as an
instance variable to a class solved the problem.
-Patrick |
|
From: Patrick G. <par...@gm...> - 2009-07-06 15:45:41
|
>> Is the crash due to that the bridging of that particular call... >> That is to say, if you were to use something like an NSInvocation to >> avoid the bridge does that allow you to work around the crash? > > You're right, its the call bridging that fails. I found this link > > https://www.ohloh.net/p/8833/commits/39267170 > > that suggests that it's a known (and fixed) problem, but not yet in > Leopard. I don't know if it's related, but I have a similar problem with [event context] in JSCocoa. http://code.google.com/p/jscocoa/issues/detail?id=61 The -context method lies about its signature, saying it's returning an ObjC object (@) while really returning some opaque stuff. Thinking it's an Objc object, the bridge retains it while boxing then crashes. Even calling [[event context] retain] in raw ObjC crashes. I don't remember whether RubyCocoa queries the ObjC runtime or BridgeSupport for method signatures. If it queries BridgeSupport you might try to hack into there and supply a different method signature, swapping the ObjC object signature (@) for a pointer (^). -Patrick |
|
From: Duncan M. <du...@on...> - 2009-07-06 13:28:36
|
Sorry to repost, but this has become a real blocker for me - I thought
I'd try one last time before giving up and re-coding in ObjC.
I can't persuade RubyCocoa to CFRelease a CGImageSourceRef without a
bus error - as a result my PDF writing code is leaking like a sieve.
require 'test/unit'
require 'osx/cocoa'
include OSX
class QuartzPDFWriterTest < Test::Unit::TestCase
def setup
@testdir = TestDir.new(self)
end
def test_dispose_CGImageSource
1.upto(10000) do |i|
p i
imageSource =
CGImageSourceCreateWithURL(NSURL.fileURLWithPath('testdata/pot pourri/
blood.jpg'), nil)
image = CGImageSourceCreateImageAtIndex(imageSource, 0, nil)
CFRelease image
CFRelease imageSource
end
end
end
CFRelease imageSource results in a segfault or bus error. For low
iteration counts this happens after the test has finished, increasing
the count makes it happen during the loop, suggesting a problem during
garbage collection I think.
If I don't CFRelease imageSource then I run out of memory to load any
more images after about 4000 iterations with my test file.
Does anyone have any ideas please?
Duncan McGregor
|
|
From: Duncan M. <du...@on...> - 2009-07-06 09:15:31
|
On 2 Jul 2009, at 14:36, Scott Thompson wrote: > Is the crash due to that the bridging of that particular call... > That is to say, if you were to use something like an NSInvocation to > avoid the bridge does that allow you to work around the crash? Sorry for single-handedly keeping this list flowing. I've tried NSInvocation with no particular success. In order to see whether it is a fundamental problem I tried to drop right down to objc_msgSend, but can't work out how to reference the function. Is there some framework or bundle that I have to load in order to get the low-level C API? Cheers Duncan |
|
From: Scott T. <ea...@ma...> - 2009-07-02 16:41:11
|
> > It's a brilliant idea to use NSInvocation, I'd forgotten all about > that stuff. Thank you for sticking with me. No problemo. I hope it works out. Sorry I so badly misread your original message. :-( |
|
From: Duncan M. <du...@on...> - 2009-07-02 15:10:06
|
On 2 Jul 2009, at 14:36, Scott Thompson wrote: > Is the crash due to that the bridging of that particular call... > That is to say, if you were to use something like an NSInvocation to > avoid the bridge does that allow you to work around the crash? You're right, its the call bridging that fails. I found this link https://www.ohloh.net/p/8833/commits/39267170 that suggests that it's a known (and fixed) problem, but not yet in Leopard. It's a brilliant idea to use NSInvocation, I'd forgotten all about that stuff. Thank you for sticking with me. Duncan |
|
From: Scott T. <ea...@ma...> - 2009-07-02 14:37:20
|
>Thanks for the attempted help ;-) but the flipped isn't the issue. It >just happens to be parameter to the call - in fact I already set a >transform into the CGContext. Ah! I misunderstood. Is the crash due to that the bridging of that particular call... That is to say, if you were to use something like an NSInvocation to avoid the bridge does that allow you to work around the crash? Scott |
|
From: Duncan M. <du...@on...> - 2009-07-02 13:21:19
|
On 2 Jul 2009, at 12:38, Scott Thompson wrote: > > On Jul 2, 2009, at 2:37 AM, Duncan McGregor wrote: > >> On Wed, Jul 1, 2009 at 11:20 PM, Scott Thompson<ea...@ma...> wrote: >> >>> If I understand... you're going all the way to NSGraphicsContext >>> just to flip the coordinate system? That's a long row to hoe :-). >> >> It would be, but I'm actually going to NSGraphicsContext so that I >> can >> draw NSImages and NSStrings on the PDF without having to bang my head >> against Quartz, especially in its font handling. > > > :-) I know what you mean, Quartz 2D doesn't have any "font handling". > I usually recommend a higher-level library like Cocoa for the text, > but then I (personally) usually use the CG level calls instead of > NSBezierPath, NSImage and friends. > > OK, the code I gave you should still work out OK with the exception of > the images. As I recall, NSImage is "smart" in that it respects the > flipped bit of the context to do what it thinks is the Right Thing™ > (although all of NSImage's "smarts" tend to bite me in the behind > often... I've heard it's much better under Snow Leopard). > > You might be able to set the flipped bit on the NSImages without > running into a RubyCocoa crash. Failing that, you can always, use > some transform magic to flip the coordinate system the right way > around right before you draw an image and then quickly put it back. Thanks for the attempted help ;-) but the flipped isn't the issue. It just happens to be parameter to the call - in fact I already set a transform into the CGContext. My problem is that I have a CGContextRef and I need to create an NSGraphicsContext from it and set it current in order for the drawing code on NSString, NSImage etc to know where to draw. Duncan |
|
From: Scott T. <ea...@ma...> - 2009-07-02 11:39:05
|
On Jul 2, 2009, at 2:37 AM, Duncan McGregor wrote: > On Wed, Jul 1, 2009 at 11:20 PM, Scott Thompson<ea...@ma...> wrote: > >> If I understand... you're going all the way to NSGraphicsContext >> just to flip the coordinate system? That's a long row to hoe :-). > > It would be, but I'm actually going to NSGraphicsContext so that I can > draw NSImages and NSStrings on the PDF without having to bang my head > against Quartz, especially in its font handling. :-) I know what you mean, Quartz 2D doesn't have any "font handling". I usually recommend a higher-level library like Cocoa for the text, but then I (personally) usually use the CG level calls instead of NSBezierPath, NSImage and friends. OK, the code I gave you should still work out OK with the exception of the images. As I recall, NSImage is "smart" in that it respects the flipped bit of the context to do what it thinks is the Right Thing™ (although all of NSImage's "smarts" tend to bite me in the behind often... I've heard it's much better under Snow Leopard). You might be able to set the flipped bit on the NSImages without running into a RubyCocoa crash. Failing that, you can always, use some transform magic to flip the coordinate system the right way around right before you draw an image and then quickly put it back. Scott |
16 messages has been excluded from this view by a project administrator.
