rubycocoa-talk — talking about RubyCocoa

Re: [Rubycocoa-talk] Install failing, at wit's end

[Jonathan P. <jp...@dc...>]

On 25 May 2005, at 10:40, Dave Howell wrote:

>> You say that it's stupid to put things in an invisible folder on a  
>> mac. I'd argue that this is only the case if the items in question  
>> are intended to be used from the GUI. ruby is not. The RubyCocoa  
>> applications you may create should be GUI-accessible, but this  
>> doesn't mean that ruby itself should be.
>
> [Danger. Rant approaching...]

:)

> I must respectfully disagree. The pinnacle of good design, as  
> Apple's guidelines support and I wholeheartedly endorse, is seen,  
> in part, when "installation" of an application involves dragging it  
> onto my hard drive, and de-installing involves dropping a folder in  
> the trash. Ruby's log file belongs in Ruby's folder (or arguably in  
> [~|]/Library/Logs/). Ruby's documentation definitely belongs in  
> Ruby's folder. I found a RubyCocoa.framework in /Library/ 
> Frameworks, exactly where I'd expect to find such a thing, and  
> where a Splat-F Find will turn it up.  If something isn't working  
> right, I should be able to hunt down folders and files with my  
> mouse, not by having to open a terminal and start digging around in  
> a foreign environment with unknown command line voodoo. (Or by  
> starting the process via Shift-Command-G and typing the initial path.)

I very much agree with the principle of drag installation and  
deinstallation. However, converting a well-established unix tool  
(ruby) to work like this is non-trivial. Since it hasn't been done  
yet, we have to work with the existing system.

Apple have done their own work on making Python more mac-friendly.  
The whole of Python lives in a framework, and symlinks from /usr/bin  
into the framework allow command-line tools to find it easily. This  
could be done with Ruby, but as far as I'm aware, it hasn't been  
tackled yet.

Log files: I don't think an application log file should ever go in  
that application's folder: Applications and their support files  
should be immutable. As you suggest, Library/Logs is the right place  
to go.

> NOTHING in the System folder is "intended to be used from the GUI."  
> e.g. to be used by the operator (me) directly. Nevertheless, Apple  
> didn't make the system folder invisible. The fact that they didn't  
> manage to actually put everything in the System folder that they  
> ought to have, that some of the files required to boot the system  
> are wandering around loose in /sbin and other places, has caused me  
> some grief when trying to repair corrupted drives. I can't just  
> duplicate the System drive and the mach files. I have to include  
> various random other directories, but not necessarily all of them.   
> Unix's 'traditional' system of /bin, /sbin, /usr/bin, /usr/local/ 
> bin, /var, /etc (et cetera, for ghu's sake?????), and other such  
> nonsense is an embarrassing artifact. We Know Better Now.

Mac OS X is built upon BSD Unix. Those random other directories you  
mention are the foundation of this system. Reworking them so they all  
hid inside /System would be a major undertaking, and would cause  
compatibility nightmares with other Unix tools.

In my opinion this duality is a good thing. We have Apple's nice GUI  
frameworks and applications on one side, and a solid Unix system on  
the other.

You say 'some of the files required to boot the system' - these  
aren't just files required to boot the system: the system *depends*  
on lots of BSD stuff in the standard unix directories, both when  
booting and during normal use.

> PostgreSQL, Webmin, and OSX-vnc were all polite enough to allow me  
> to put them where I could see them (to wit, in the /Servers folder  
> on my server, where *I* want them to be). I don't know where  
> Postfix or BIND actually live, since they came invisibly with the  
> OS. So did Ruby, for that matter, which is related to the 1.8's  
> failure to install; information about the need to reconfigure my  
> "path" command was not part of the two or three different opinions  
> I found on how to install it. Ruby and TeX are the only apps (so  
> far) that offered to let me pick a place for them to install, but  
> then failed to run unless allowed their default locations. (A much  
> more egregious fault in TeX, since I have to keep installing new  
> stuff in the part of the tree where local user files go.)  
> GhostScript may or may not have also done that, since I don't know  
> if the install I did is still there or not after a couple of OS  
> upgrades; it installed invisibly in an unknown location.

Unfortunately, I think the current state of Ruby on OSX is such that  
it's not quite ready for use without some command line hackery.  
Indeed, it's still very much like any other Unix tool. If installed  
to a non-standard location, it's necessary to include the  
installation bin directory in the PATH environment variable to let  
the shell know where to look for it.

>> The proper way
>>
>
> I'm afraid I find the following definition of "proper" to be  
> appallingly Unix-command-line-centric, and very much at odds with  
> Apple's standards of propriety.

You're right - they are command line centric - and will remain that  
way until Ruby-on-OSX is further developed.

> And should I happen to ssh in and get a different shell, or log in  
> as a different user?
> On my laptop, if I write an AppleScript and include
>     do shell script "ruby -v"
> it will fail, ONLY because I deleted /usr/bin/ruby. Thank God. If I  
> hadn't, it would be invoking the old version and make debugging a  
> bloody nightmare. (Holy Cow. If, instead, I try
>     $ osascript -e 'do shell script "ruby -v" '
> then I get ruby 1.8.2. )

You can avoid the uncertainty by giving the full path to your  
installed ruby:

    do shell script "/path/to/your/ruby -v"

I realise you may not care, but... the reason the AppleScript doesn't  
work but using osascript does is due to the way the PATH environment  
variable works. The PATH is inherited from the process that starts a  
given program. So, in the AppleScript example, the PATH comes via  
Script Editor (for example), which is eventually rooted in the  
LoginWindow process. Compare this with running from a terminal, where  
the PATH has been updated by whatever commands you needed to add to  
make this happen. The 'osascript' command sees this updated PATH, and  
therefore knows where to find the appropriate ruby.

I believe it's possible to change the login-session PATH by editing a  
plist somewhere in ~/Library/Preferences (IIRC). I'm not sure where  
it is off-hand though.

>> It should never be necessary to modify some Apple-installed system  
>> files (like /usr/bin/ruby).
>>
>
> And if installing a 'newer' version of Ruby had gone as expected, I  
> wouldn't have had to. When I install Word 2003, I expect that, even  
> if Word 2001 remains on my drive, my files will now use the newer  
> version. When I install OSX 10.3, I expect 10.2 to be overwritten.  
> When I install Ruby 1.8.2, I expect to get Ruby 1.8.2 when I type  
> "ruby." (cd /usr/bin; rm /ruby; ln /usr/local/bin/ruby) There. NOW  
> my install is actually right. Except for some unknown amount of  
> 1.6.8 stuff still hiding out, er, somewhere.

I'm sorry to say that this boils down again to the difference between  
the Mac and Unix ways of doing things. Ruby is not yet ready for the  
Mac way.

Re: [Rubycocoa-talk] Install failing, at wit's end

[Dave H. <gr...@gr...>]

On May 24, 2005, at 8:43 AM, kimura wataru wrote:

> Older version of RubyCocoa has a problem as you said.
> branch-devel-panther was merged to trunk before release of 0.4.1. This
> branch is not in maintenance.

But it is RubyCocoa 0.4.1 that I installed. . . .

 From file VERSION

VERSION = "0.4.1"
STAGE = "devel-panther"
RELEASE_DATE = "2003-12-04"

I have no idea what "branch-devel-panther was merged to trunk" means.

Re: [Rubycocoa-talk] Install failing, at wit's end

[Dave H. <gr...@gr...>]

On May 23, 2005, at 4:54 PM, Jonathan Paisley wrote:

> A general comment about moving ruby around: it sounds like things got 
> initially got confused because you moved ruby to a different path 
> after installing it. ruby has compile-time paths embedded in it for 
> the standard library.

Not after. I told it to install itself somewhere else in the first 
place. It was compiled into /Library/Ruby.

> You say that it's stupid to put things in an invisible folder on a 
> mac. I'd argue that this is only the case if the items in question are 
> intended to be used from the GUI. ruby is not. The RubyCocoa 
> applications you may create should be GUI-accessible, but this doesn't 
> mean that ruby itself should be.

[Danger. Rant approaching...]

I must respectfully disagree. The pinnacle of good design, as Apple's 
guidelines support and I wholeheartedly endorse, is seen, in part, when 
"installation" of an application involves dragging it onto my hard 
drive, and de-installing involves dropping a folder in the trash. 
Ruby's log file belongs in Ruby's folder (or arguably in 
[~|]/Library/Logs/). Ruby's documentation definitely belongs in Ruby's 
folder. I found a RubyCocoa.framework in /Library/Frameworks, exactly 
where I'd expect to find such a thing, and where a Splat-F Find will 
turn it up.  If something isn't working right, I should be able to hunt 
down folders and files with my mouse, not by having to open a terminal 
and start digging around in a foreign environment with unknown command 
line voodoo. (Or by starting the process via Shift-Command-G and typing 
the initial path.)

NOTHING in the System folder is "intended to be used from the GUI." 
e.g. to be used by the operator (me) directly. Nevertheless, Apple 
didn't make the system folder invisible. The fact that they didn't 
manage to actually put everything in the System folder that they ought 
to have, that some of the files required to boot the system are 
wandering around loose in /sbin and other places, has caused me some 
grief when trying to repair corrupted drives. I can't just duplicate 
the System drive and the mach files. I have to include various random 
other directories, but not necessarily all of them.  Unix's 
'traditional' system of /bin, /sbin, /usr/bin, /usr/local/bin, /var, 
/etc (et cetera, for ghu's sake?????), and other such nonsense is an 
embarrassing artifact. We Know Better Now.

PostgreSQL, Webmin, and OSX-vnc were all polite enough to allow me to 
put them where I could see them (to wit, in the /Servers folder on my 
server, where *I* want them to be). I don't know where Postfix or BIND 
actually live, since they came invisibly with the OS. So did Ruby, for 
that matter, which is related to the 1.8's failure to install; 
information about the need to reconfigure my "path" command was not 
part of the two or three different opinions I found on how to install 
it. Ruby and TeX are the only apps (so far) that offered to let me pick 
a place for them to install, but then failed to run unless allowed 
their default locations. (A much more egregious fault in TeX, since I 
have to keep installing new stuff in the part of the tree where local 
user files go.) GhostScript may or may not have also done that, since I 
don't know if the install I did is still there or not after a couple of 
OS upgrades; it installed invisibly in an unknown location.

> The proper way

I'm afraid I find the following definition of "proper" to be 
appallingly Unix-command-line-centric, and very much at odds with 
Apple's standards of propriety.

> to identify which version of ruby you want to use (Apple's on /usr/bin 
> or self-installed in /usr/local/bin) is to update your PATH (using 
> 'setenv' for tcsh or 'export' for bash/zsh).

I didn't have a path command. I didn't have a .login or .bash_login or 
whichever of an exasperating variety of possible invisible files I 
would have to have in order to be able to reconfigure my path. And 
apparently whatever command accomplishes that task depends on what 
shell I'm using, so now I have to know that too? (Which, oh, yea, 
*changed* from 10.2 to 10.3) Yes, indeed, which is why it took me hours 
of searching the web to find out how to actually get my path to change 
and stay changed, when a different unfriendly application required it.

And should I happen to ssh in and get a different shell, or log in as a 
different user?
On my laptop, if I write an AppleScript and include
	do shell script "ruby -v"
it will fail, ONLY because I deleted /usr/bin/ruby. Thank God. If I 
hadn't, it would be invoking the old version and make debugging a 
bloody nightmare. (Holy Cow. If, instead, I try
	$ osascript -e 'do shell script "ruby -v" '
then I get ruby 1.8.2. )

No, that can only reaffirm my belief that obliterating or replacing the 
'old' Ruby is the only smart thing to do. If I absolutely destroy it, 
then it can't surprise me later. And I don't need to Google up the 
secret to deleting files. I just had to figure out where Apple hid 
their Ruby in the first place.

> It should never be necessary to modify some Apple-installed system 
> files (like /usr/bin/ruby).

And if installing a 'newer' version of Ruby had gone as expected, I 
wouldn't have had to. When I install Word 2003, I expect that, even if 
Word 2001 remains on my drive, my files will now use the newer version. 
When I install OSX 10.3, I expect 10.2 to be overwritten. When I 
install Ruby 1.8.2, I expect to get Ruby 1.8.2 when I type "ruby." (cd 
/usr/bin; rm /ruby; ln /usr/local/bin/ruby) There. NOW my install is 
actually right. Except for some unknown amount of 1.6.8 stuff still 
hiding out, er, somewhere.

So now I have a "textbook" 1.8.2 install on my laptop that didn't 
actually install itself correctly (by overwriting or moving 1.6.x) 
which means that the Installer.dmg that somebody made for RubyCocoa 
can't be used on 1.8.2. This may or may not also be what's preventing 
RubyCocoa from installing correctly; I don't know, and I don't know of 
any way to definitively uninstall 1.6.8, since there's no uninstaller, 
and I can't just throw away a folder named "Ruby 1.6.8".

What little I've managed to get done with Ruby so far has made me like 
it a lot. Good thing, since I haven't had a single ruby-related system 
yet install itself in a way that resulted in working software. Not 
Ruby, not RubyCocoa, not RubyOnRails.

Well, it could be worse. Gimp/GhostScript/Foomatic is a friggin' 
nightmare....

Re: [Rubycocoa-talk] Install failing, at wit's end

[Dave H. <gr...@gr...>]

On May 23, 2005, at 4:54 PM, Jonathan Paisley wrote:

>>>>
>>>> /Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/ruby/ 
>>>> osx/objc/oc_import.rb:22:in `module_eval': undefined method  
>>>> `NSClassFromString' for OSX:Module (NoMethodError)
>>>>
>>>> So, um, I guess that the OSX module getting included in RubyCocoa's  
>>>> not doing its job somehow?
>
> This error occurs if the native module hasn't been loaded.

>
> Try adding:
>
>   require 'rubycocoa'
>
> right at the beginning of rb_main.rb.
>
> However, it shouldn't be necessary to do this since the compiled xcode  
> project already references the framework.

That did not change the results.

> How are you running the program? From Xcode or using ruby from the  
> command line?

XCode, "Build and Run."

> If you have built and are running the native program, please mail the  
> output from running 'otool -L' on the application main program. For  
> example, if your program was called MyProg.app, you'd try something  
> like this:
>
> $ otool -L MyProg.app/Contents/MacOS/MyProg

$ otool -L RubyCocoaTar.app/Contents/MacOS/RubyCocoaTar
RubyCocoaTar.app/Contents/MacOS/RubyCocoaTar:
         /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa  
(compatibility version 1.0.0, current version 9.0.0)
          
@executable_path/../Frameworks/RubyCocoa.framework/Versions/A/RubyCocoa  
(compatibility version 1.0.0, current version 1.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
current version 71.1.3)

Re: [Rubycocoa-talk] Install failing, at wit's end

[kimura w. <ki...@us...>]

Hi,


Sun, 22 May 2005 12:45:10 -0700, Dave Howell wrote:
>
>I posted a  pretty detailed description of the whole thing on  
>O'Reilly's web site in the discussion  area of the "An Introduction to  
>RubyCocoa, Part 2" article.  
>http://www.macdevcenter.com/pub/a//mac/2004/10/12/cocoa.html? 
>page=last#thread  Look for the thread entitled "Installer Grief,"  
>although I think you can ignore the first message.
>
>In a nutshell, I installed RubyCocoa Panther 0.4.1 via CVS,  and got  
>the following during the Make run:

Older version of RubyCocoa has a problem as you said. 
branch-devel-panther was merged to trunk before release of 0.4.1. This 
branch is not in maintenance.

RubyCocoa 0.4.1 source code distribution is here:
http://prdownloads.sourceforge.net/rubycocoa/rubycocoa-0.4.1.tgz?download

Getting latest code from CVS:
http://rubycocoa.sourceforge.net/doc/getting.en.html#label-18

 
-- 
kimura wataru

Re: [Rubycocoa-talk] Install failing, at wit's end

[Jonathan P. <jp...@dc...>]

On 22 May 2005, at 20:45, Dave Howell wrote:

> On May 17, 2005, at 9:10 AM, Jonathan Paisley wrote:
>
>> On 15 May 2005, at 20:49, Dave Howell wrote:
>>
>>> I have tried installing RubyCocoa repeatedly, carefully following  
>>> all the instructions, and scrubbing things out a few times, but  
>>> nothing I've done has given me a functioning installation. It may  
>>> not even be RubyCocoa's fault; the error message is so massively  
>>> cryptic that I can't trace it any farther.
>>>
>>> /Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/ruby/ 
>>> osx/objc/oc_import.rb:22:in `module_eval': undefined method  
>>> `NSClassFromString' for OSX:Module (NoMethodError)
>>>
>>> So, um, I guess that the OSX module getting included in  
>>> RubyCocoa's not doing its job somehow?

This error occurs if the native module hasn't been loaded.

Normally, when you run your program from a compiled xcode project,  
the main application gets linked with the RubyCocoa framework, and it  
takes care of starting the Cocoa application and initialising the  
ruby interpreter. As a result, it's not necessary to "require  
'rubycocoa'" within the program at any time. On the other hand, if  
you run your script from the command line, the rubycocoa require is  
necessary. The osx/*rb code should be handling this automatically,  
but I think it perhaps isn't at the moment (I haven't investigated  
this in detail).

Try adding:

   require 'rubycocoa'

right at the beginning of rb_main.rb.

However, it shouldn't be necessary to do this since the compiled  
xcode project already references the framework.

>>>
>>>
>>> >ruby -v
>>> ruby 1.8.2 (2004-11-03) [powerpc-darwin7.5.0]
>>
>> Can you post a complete IRB session or script that you're trying?
>>
>> What version of Mac OS X are you using?
>>
>> Where did your ruby come from?
>>
>
> I posted a  pretty detailed description of the whole thing on  
> O'Reilly's web site in the discussion  area of the "An Introduction  
> to RubyCocoa, Part 2" article. http://www.macdevcenter.com/pub/a// 
> mac/2004/10/12/cocoa.html?page=last#thread  Look for the thread  
> entitled "Installer Grief," although I think you can ignore the  
> first message.

A general comment about moving ruby around: it sounds like things got  
initially got confused because you moved ruby to a different path  
after installing it. ruby has compile-time paths embedded in it for  
the standard library.

You say that it's stupid to put things in an invisible folder on a  
mac. I'd argue that this is only the case if the items in question  
are intended to be used from the GUI. ruby is not. The RubyCocoa  
applications you may create should be GUI-accessible, but this  
doesn't mean that ruby itself should be.

The proper way to identify which version of ruby you want to use  
(Apple's on /usr/bin or self-installed in /usr/local/bin) is to  
update your PATH (using 'setenv' for tcsh or 'export' for bash/zsh).

It should never be necessary to modify some Apple-installed system  
files (like /usr/bin/ruby).

>
> In a nutshell, I installed RubyCocoa Panther 0.4.1 via CVS,  and  
> got the following during the Make run:
>
> gcc -fno-common -F../../framework/build -framework RubyCocoa  -I. - 
> I/usr/local/lib/ruby/1.8/powerpc-darwin7.5.0 -I/usr/local/lib/ruby/ 
> 1.8/powerpc-darwin7.5.0 -I/Users/snarke/Personal/Programming/Ruby/ 
> rubycocoa-panther/ext/rubycocoa    -c -o rubycocoa.o rubycocoa.m
>
> gcc: -framework: linker input file unused because linking not done
>
> gcc: RubyCocoa: linker input file unused because linking not done
>
> Then I built the script presented in the article by following the  
> instructions *precisely,* but that just gets me the NoMethodError.  
> I've also tried a completely unrelated Ruby script (somebody else's  
> example using a variant of CurrencyConverter) and gotten exactly  
> the same error message (above).

How are you running the program? From Xcode or using ruby from the  
command line?

If you have built and are running the native program, please mail the  
output from running 'otool -L' on the application main program. For  
example, if your program was called MyProg.app, you'd try something  
like this:

$ otool -L MyProg.app/Contents/MacOS/MyProg

  (assuming you're in the directory containing MyProg.app)

Re: [Rubycocoa-talk] Install failing, at wit's end

[Dave H. <gr...@gr...>]

On May 17, 2005, at 9:10 AM, Jonathan Paisley wrote:
> On 15 May 2005, at 20:49, Dave Howell wrote:
>> I have tried installing RubyCocoa repeatedly, carefully following all  
>> the instructions, and scrubbing things out a few times, but nothing  
>> I've done has given me a functioning installation. It may not even be  
>> RubyCocoa's fault; the error message is so massively cryptic that I  
>> can't trace it any farther.
>>
>> /Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/ruby/ 
>> osx/objc/oc_import.rb:22:in `module_eval': undefined method  
>> `NSClassFromString' for OSX:Module (NoMethodError)
>>
>> So, um, I guess that the OSX module getting included in RubyCocoa's  
>> not doing its job somehow?
>>
>> >ruby -v
>> ruby 1.8.2 (2004-11-03) [powerpc-darwin7.5.0]
>
> Can you post a complete IRB session or script that you're trying?
>
> What version of Mac OS X are you using?
>
> Where did your ruby come from?

I posted a  pretty detailed description of the whole thing on  
O'Reilly's web site in the discussion  area of the "An Introduction to  
RubyCocoa, Part 2" article.  
http://www.macdevcenter.com/pub/a//mac/2004/10/12/cocoa.html? 
page=last#thread  Look for the thread entitled "Installer Grief,"  
although I think you can ignore the first message.

In a nutshell, I installed RubyCocoa Panther 0.4.1 via CVS,  and got  
the following during the Make run:

gcc -fno-common -F../../framework/build -framework RubyCocoa  -I.  
-I/usr/local/lib/ruby/1.8/powerpc-darwin7.5.0  
-I/usr/local/lib/ruby/1.8/powerpc-darwin7.5.0  
-I/Users/snarke/Personal/Programming/Ruby/rubycocoa-panther/ext/ 
rubycocoa    -c -o rubycocoa.o rubycocoa.m

gcc: -framework: linker input file unused because linking not done

gcc: RubyCocoa: linker input file unused because linking not done

Then I built the script presented in the article by following the  
instructions *precisely,* but that just gets me the NoMethodError. I've  
also tried a completely unrelated Ruby script (somebody else's example  
using a variant of CurrencyConverter) and gotten exactly the same error  
message (above).

I installed Ruby 1.8.2 some time last summer; I don't really recall how  
it got there, although I know I'd walked past/through Rubygarden as  
part of the process, so it probably came from sourceforge somehow.

My OS is currently 10.3.9, although I've had the same problem under  
.3.8 and .3.7 as well.

Re: [Rubycocoa-talk] Install failing, at wit's end

[Jonathan P. <jp...@dc...>]

On 15 May 2005, at 20:49, Dave Howell wrote:

> I have tried installing RubyCocoa repeatedly, carefully following  
> all the instructions, and scrubbing things out a few times, but  
> nothing I've done has given me a functioning installation. It may  
> not even be RubyCocoa's fault; the error message is so massively  
> cryptic that I can't trace it any farther.
>
> /Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/ruby/ 
> osx/objc/oc_import.rb:22:in `module_eval': undefined method  
> `NSClassFromString' for OSX:Module (NoMethodError)
>
> So, um, I guess that the OSX module getting included in RubyCocoa's  
> not doing its job somehow?
>
> >ruby -v
> ruby 1.8.2 (2004-11-03) [powerpc-darwin7.5.0]

Can you post a complete IRB session or script that you're trying?

What version of Mac OS X are you using?

Where did your ruby come from?

[Rubycocoa-talk] Install failing, at wit's end

[Dave H. <rub...@gr...>]

I have tried installing RubyCocoa repeatedly, carefully following all  
the instructions, and scrubbing things out a few times, but nothing  
I've done has given me a functioning installation. It may not even be  
RubyCocoa's fault; the error message is so massively cryptic that I  
can't trace it any farther.

/Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/ruby/osx/ 
objc/oc_import.rb:22:in `module_eval': undefined method  
`NSClassFromString' for OSX:Module (NoMethodError)

So, um, I guess that the OSX module getting included in RubyCocoa's not  
doing its job somehow?

 >ruby -v
ruby 1.8.2 (2004-11-03) [powerpc-darwin7.5.0]

Re: [Rubycocoa-talk] Glue-code between NSOutlineView and Controller

[Remo E. <re...@pl...>]

ok, i've found my problem, it was that i've used  
"tableViewSelectionDidChange" and NOT  
"outlineViewSelectionDidChange". sorry i'm new on Cocoa/Objective-C   
and Mac development.

Am 30.04.2005 um 22:54 schrieb Remo Eichenberger:

> i see in the RubyRaiseMan sample the usage of  
> "tableViewSelectionDidChange". i would check this sample.
>
>
> Am 30.04.2005 um 20:34 schrieb Remo Eichenberger:
>
>
>> hi, (sorry for my english)
>>
>> i don't understand how i can react on events from NSOutlineView in  
>> the controller. I have a NSOutlineView. on that i have set the  
>> "delegate" to the Controller.
>>
>> class Controller < OSX::NSResponder
>>
>>     ib_outlets  :oglView
>>     ib_outlets  :sceneView
>>     ib_outlets  :propertyView
>>     ib_outlets  :propertyDataSource
>>
>>     ns_overrides :acceptsFirstResponder
>>     ns_overrides :keyDown_
>>
>>     def keyDown(sender)
>>         puts "KEYDOWN"
>>     end
>>
>>     def outlineView_clickedRow(sender)
>>         puts "CLICKED"
>>     end
>> end
>>
>> the keyDown-event works but NOT the outlineView_clickedRow.
>>
>> what i make wrong ?
>>
>> thanks
>>
>> Remo Eichenberger
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: NEC IT Guy Games.
>> Get your fingers limbered up and give it your best shot. 4 great  
>> events, 4
>> opportunities to win big! Highest score wins.NEC IT Guy Games.  
>> Play to
>> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
>> _______________________________________________
>> Rubycocoa-talk mailing list
>> Rub...@li...
>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great  
> events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>

Re: [Rubycocoa-talk] Glue-code between NSOutlineView and Controller

[Remo E. <re...@pl...>]

i see in the RubyRaiseMan sample the usage of  
"tableViewSelectionDidChange". i would check this sample.


Am 30.04.2005 um 20:34 schrieb Remo Eichenberger:

> hi, (sorry for my english)
>
> i don't understand how i can react on events from NSOutlineView in  
> the controller. I have a NSOutlineView. on that i have set the  
> "delegate" to the Controller.
>
> class Controller < OSX::NSResponder
>
>     ib_outlets  :oglView
>     ib_outlets  :sceneView
>     ib_outlets  :propertyView
>     ib_outlets  :propertyDataSource
>
>     ns_overrides :acceptsFirstResponder
>     ns_overrides :keyDown_
>
>     def keyDown(sender)
>         puts "KEYDOWN"
>     end
>
>     def outlineView_clickedRow(sender)
>         puts "CLICKED"
>     end
> end
>
> the keyDown-event works but NOT the outlineView_clickedRow.
>
> what i make wrong ?
>
> thanks
>
> Remo Eichenberger
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great  
> events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>

[Rubycocoa-talk] Glue-code between NSOutlineView and Controller

[Remo E. <re...@pl...>]

hi, (sorry for my english)

i don't understand how i can react on events from NSOutlineView in  
the controller. I have a NSOutlineView. on that i have set the  
"delegate" to the Controller.

class Controller < OSX::NSResponder

     ib_outlets  :oglView
     ib_outlets  :sceneView
     ib_outlets  :propertyView
     ib_outlets  :propertyDataSource

     ns_overrides :acceptsFirstResponder
     ns_overrides :keyDown_

     def keyDown(sender)
         puts "KEYDOWN"
     end

     def outlineView_clickedRow(sender)
         puts "CLICKED"
     end
end

the keyDown-event works but NOT the outlineView_clickedRow.

what i make wrong ?

thanks

Remo Eichenberger

Re: [Rubycocoa-talk] Bindings working with notification from Ruby

[Jonathan P. <jp...@dc...>]

On 26 Apr 2005, at 16:08, kimura wataru wrote:

> I'm sorry my reply is too late.

No problem at all.

> It's cool! If you allow, I will add kvc_accessor to RubyCocoa.

Yes, please do.

> btw, Module#method_added enables to hook method definition. Following
> code reverts a wrapper of a setter when the setter is overrided.
 > [snip code]

Ah! Looks good. I will try it out.

I've attached a patch to this message that extends the base Ruby-Cocoa  
bridge class methods. addRubyMethod_withType allows creation of an  
actual ObjC method corresponding to a ruby method. This means that  
key-value coding will be able to find the actual method when it does a  
lookup.

This could be used to define real accessor methods (therefore avoiding  
the valueForUndefinedKey hook), or for implementing array accessors  
(which have no such hook). For example:

     def kvc_array_accessor(*args)
       kvc_accessor(*args)
       args.each do |v|
         n = v.to_s
         n[0..0] = n[0..0].upcase
         self.addRubyMethod_withType("countOf#{n}".to_sym,"i4@8:12")
          
self.addRubyMethod_withType("objectIn#{n}AtIndex_".to_sym,"@4@8:12i16")
          
self.addRubyMethod_withType("insertObject_in#{n}AtIndex_".to_sym,"@4@8: 
12@16i20")
          
self.addRubyMethod_withType("removeObjectFrom#{n}AtIndex_".to_sym,"@4@8: 
12i16")
         # ...

I've attached an updated version of ObjcID that has the full  
implementation of this method.

Thanks
Jonathan

Re: [Rubycocoa-talk] exception in rubycocoa

[Remo E. <re...@pl...>]

Hi, (sorry for my english)

thank you for your info with "-d". with this info i found my problem. i 
returned native-ruby-objects in the datasource for the NSOutlineView. i 
think this object was wrapped by rubycocoa only temporary. i looked at 
your sample CocoaRBBR. i see that you use the "ObjectSpace" to 
transform from a instance-id to a ruby-nativ-object. i think many users 
don't understand this, so an entry in the FAQ would be good :)

regards,

Remo Eichenberger

Am 27.04.2005 um 18:07 schrieb kimura wataru:

> Hi,
>
> Please show me a debug log of your application. A debug log is 
> displayed
> when your app is running with -d option.
>
> I think the last 40 lines of your debug log are enough to solve this
> problem.
>
> on Terminal:
>   $ ./YourApp.app/Contents/MacOS/YourApp -d
>
> a sample of debug log:
>   2005-04-28 00:53:40.348 TMPresents[7066] RBOBJ:   --> 0
>   2005-04-28 00:53:40.348 TMPresents[7066] 
> RBOBJ:respondsToSelector(isEditable)
>   2005-04-28 00:53:40.348 TMPresents[7066] 
> RBOBJ:rbobjRespondsToSelector(isEditabl
>   e)
>   2005-04-28 00:53:40.348 TMPresents[7066] RBOBJ:   --> 0
>   2005-04-28 00:53:40.348 TMPresents[7066] RBOBJ:   --> 0
>   2005-04-28 00:53:40.495 TMPresents[7066] 
> RBOBJ:respondsToSelector(resignKeyWindo
>   w)
>   2005-04-28 00:53:40.495 TMPresents[7066] 
> RBOBJ:rbobjRespondsToSelector(resignKey
>   Window)
>   2005-04-28 00:53:40.496 TMPresents[7066] RBOBJ:   --> 0
>   2005-04-28 00:53:40.496 TMPresents[7066] RBOBJ:   --> 0
>
>
>
> Tue, 26 Apr 2005 00:20:39 +0200, Remo Eichenberger wrote:
>> hi all
>>
>> i have a exception when i implement the following datasource: (i know
>> the source is not complete)
>>
>
>> is it a bug or i make the things wrong ?
>
>
> -- 
> kimura wataru
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

Re: [Rubycocoa-talk] exception in rubycocoa

[kimura w. <ki...@us...>]

Hi,

Please show me a debug log of your application. A debug log is displayed
when your app is running with -d option. 

I think the last 40 lines of your debug log are enough to solve this 
problem.

on Terminal:
  $ ./YourApp.app/Contents/MacOS/YourApp -d

a sample of debug log:
  2005-04-28 00:53:40.348 TMPresents[7066] RBOBJ:   --> 0
  2005-04-28 00:53:40.348 TMPresents[7066] RBOBJ:respondsToSelector(isEditable)
  2005-04-28 00:53:40.348 TMPresents[7066] RBOBJ:rbobjRespondsToSelector(isEditabl
  e)
  2005-04-28 00:53:40.348 TMPresents[7066] RBOBJ:   --> 0
  2005-04-28 00:53:40.348 TMPresents[7066] RBOBJ:   --> 0
  2005-04-28 00:53:40.495 TMPresents[7066] RBOBJ:respondsToSelector(resignKeyWindo
  w)
  2005-04-28 00:53:40.495 TMPresents[7066] RBOBJ:rbobjRespondsToSelector(resignKey
  Window)
  2005-04-28 00:53:40.496 TMPresents[7066] RBOBJ:   --> 0
  2005-04-28 00:53:40.496 TMPresents[7066] RBOBJ:   --> 0



Tue, 26 Apr 2005 00:20:39 +0200, Remo Eichenberger wrote:
>hi all
>
>i have a exception when i implement the following datasource: (i know  
>the source is not complete)
>

>is it a bug or i make the things wrong ?


-- 
kimura wataru

Re: [Rubycocoa-talk] Bindings working with notification from Ruby

[kimura w. <ki...@us...>]

Hi,

I'm sorry my reply is too late.

Tue, 12 Apr 2005 10:38:50 +0100, Jonathan Paisley wrote:
>Hi,
>
>After following the instructions on the FAQ [1], with a few fiddles, I 
>have got Cocoa bindings on a Ruby object to work well. Please let me 
>know what you think of these modifications - if they seem ok I'll try 
>to update the Wiki FAQ page.
>
>The main thing I wanted to support was notification from Ruby to Cocoa 
>upon changing a value in Ruby.
>

>The kvc_accessor meta-method takes care of wrapping the setter (key=) 
>with the Cocoa bindings notifications. If the setter is already 
>defined, it will be wrapped by the kvc_accessor:
>
>   class MyModel < OSX::NSObject
>     def foo=(value)
>       @foo = value
>       @foo_parsed = ... # do some parsing of foo
>     end
>
>     kvc_accessor :foo # wraps foo= with notification, also defines foo 
>reader method
>   end
>
>Now, in other code, if you do 'model.foo = "Something"', any GUI 
>objects bound will automatically update.
>

It's cool! If you allow, I will add kvc_accessor to RubyCocoa.

btw, Module#method_added enables to hook method definition. Following
code reverts a wrapper of a setter when the setter is overrided.


module NSBehaviorAttachment
  def kvc_accessor(*keys)
    # define setter if needed
    # alias setter to internal setter
    # define wrapper
    # alias wrapper to setter
  end

  def kvc_internal_setter(key)
    # returns wrapped setter name
  end

  def kvc_setter_wrapper(key)
    # returns wrapper name
  end

  def method_added(sym)
    return unless sym.to_s =~ /([^=]+)=\z/
    key = $1

    setter = kvc_internal_setter(key)
    wrapper = kvc_setter_wrapper(key)
    return unless method_defined?(setter) && method_defined?(wrapper)

    # do not re-alias wrapper 
    return if self.instance_method(wrapper) == self.instance_method(sym)

    # re-alias wrapper to setter
    alias_method sym, wrapper
  end
end



-- 
kimura wataru

[Rubycocoa-talk] exception in rubycocoa

[Remo E. <re...@pl...>]

hi all

i have a exception when i implement the following datasource: (i know  
the source is not complete)

( the exeption throws when i expand a folder)

		def outlineView_numberOfChildrenOfItem(outlineView, item)
			if item.nil?
				if @scene.nil?
					return 0
				else
					return 1
				end
			else
				return item.children.count
			end
		end
		
		def outlineView_isItemExpandable(outlineView, item)
			outlineView_numberOfChildrenOfItem(outlineView, item) > 0
		end

		def outlineView_child_ofItem(outlineView, index, item)
			if item.nil?
				return @scene
			else
				return item.children.objectAtIndex(index)
			end
		end

		def outlineView_objectValueForTableColumn_byItem(outlineView, column,  
item)
			
			case column.identifier.to_s
				when 'name'
					'name'
				when 'values'
					"value"
			end
		end

is it a bug or i make the things wrong ?

regards,
Remo

------------ EXCEPTION  
------------------------------------------------------------------------ 
-------------------

Date/Time:      2005-04-26 00:11:45 +0200
OS Version:     10.3.9 (Build 7W98)
Report Version: 2

PID:     2231
Thread:  0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x10a321ac

Thread 0 Crashed:
0   libobjc.A.dylib          	0x90831204 objc_msgSend + 0x24
1   ???                      	0x00345fe8 ocid_get_rbobj + 0x6c
2   ???                      	0x0031b6c0 ocid_to_rbobj + 0x28
3   ???                      	0x0031ae7c ocdata_to_rbobj + 0x120
4   ???                      	0x0031d3b4  
override_mixin_class_method_list + 0x858
5   ???                      	0x0031d584  
override_mixin_class_method_list + 0xa28
6   ???                      	0x0031d918  
override_mixin_class_method_list + 0xdbc
7   ???                      	0x0031c84c rbobj_to_ocdata + 0x968
8   com.apple.Foundation     	0x90a2d960  
-[NSObject(NSForwardInvocation) forward::] + 0x198
9   libobjc.A.dylib          	0x90836810 _objc_msgForward + 0xb0
10  com.apple.AppKit         	0x92e9d82c -[NSTableView  
drawRow:clipRect:] + 0x13c
11  com.apple.AppKit         	0x92f1986c -[NSOutlineView  
drawRow:clipRect:] + 0xec
12  com.apple.AppKit         	0x92ecf234 -[NSTableView drawRect:] +  
0x378
13  com.apple.AppKit         	0x92e775a4 -[NSView _drawRect:clip:] +  
0x770
14  com.apple.AppKit         	0x92e87fe8 -[NSView  
_recursiveDisplayAllDirtyWithLockFocus:visRect:] + 0xe8
15  com.apple.AppKit         	0x92ebdd60 _recursiveDisplayInRect2 + 0x54
16  com.apple.CoreFoundation 	0x901cf16c CFArrayApplyFunction + 0x198
17  com.apple.AppKit         	0x92e880ec -[NSView  
_recursiveDisplayAllDirtyWithLockFocus:visRect:] + 0x1ec
18  com.apple.AppKit         	0x92e738f4 -[NSView  
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect: 
rectIsVisibleRectForView:topView:] + 0x9c
19  com.apple.AppKit         	0x92e73d10 -[NSView  
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect: 
rectIsVisibleRectForView:topView:] + 0x4b8
20  com.apple.AppKit         	0x92e73d10 -[NSView  
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect: 
rectIsVisibleRectForView:topView:] + 0x4b8
21  com.apple.AppKit         	0x92e73d10 -[NSView  
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect: 
rectIsVisibleRectForView:topView:] + 0x4b8
22  com.apple.AppKit         	0x92e73d10 -[NSView  
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect: 
rectIsVisibleRectForView:topView:] + 0x4b8
23  com.apple.AppKit         	0x92e73d10 -[NSView  
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect: 
rectIsVisibleRectForView:topView:] + 0x4b8
24  com.apple.AppKit         	0x92ec0880 -[NSFrameView  
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect: 
rectIsVisibleRectForView:topView:] + 0x124
25  com.apple.AppKit         	0x92ea7a04 -[NSThemeFrame  
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect: 
rectIsVisibleRectForView:topView:] + 0xc0
26  com.apple.AppKit         	0x92e84bbc -[NSView  
_displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] +  
0x180
27  com.apple.AppKit         	0x92e9dbec -[NSView displayIfNeeded] +  
0xa8
28  com.apple.AppKit         	0x92eae8dc -[NSWindow displayIfNeeded] +  
0xb4
29  com.apple.AppKit         	0x92e8ef24 _handleWindowNeedsDisplay +  
0xe0
30  com.apple.CoreFoundation 	0x901c1c80 __CFRunLoopDoObservers + 0x194
31  com.apple.CoreFoundation 	0x901c151c __CFRunLoopRun + 0x18c
32  com.apple.CoreFoundation 	0x901c5e6c CFRunLoopRunSpecific + 0x148
33  com.apple.HIToolbox      	0x92885f60 RunCurrentEventLoopInMode +  
0xac
34  com.apple.HIToolbox      	0x9288c640 ReceiveNextEventCommon + 0xf4
35  com.apple.HIToolbox      	0x928ae6a0  
BlockUntilNextEventMatchingListInMode + 0x60
36  com.apple.AppKit         	0x92e827bc _DPSNextEvent + 0x180
37  com.apple.AppKit         	0x92e99240 -[NSApplication  
nextEventMatchingMask:untilDate:inMode:dequeue:] + 0x74
38  com.apple.AppKit         	0x92ead5c0 -[NSApplication run] + 0x21c
39  com.apple.AppKit         	0x92f69cc4 NSApplicationMain + 0x1d0
40  ???                      	0x003222fc init_NSAlert + 0x4a4
41  ???                      	0x00371430 rb_throw + 0x260
42  ???                      	0x00363ea0 rb_with_disable_interrupt +  
0x79c
43  ???                      	0x00364800 rb_with_disable_interrupt +  
0x10fc
44  ???                      	0x0035ee58 rb_Array + 0x1e84
45  ???                      	0x0035a404 ruby_init + 0x38c
46  ???                      	0x0035aa28 ruby_cleanup + 0x250
47  ???                      	0x0035aa84 ruby_exec + 0x18
48  ???                      	0x0035aacc ruby_run + 0x38
49  ???                      	0x0031de98 RBRubyCocoaInit + 0
50  ???                      	0x00001dfc main + 0x30 (main.m:13)
51  ???                      	0x000018bc _start + 0x188 (crt.c:267)
52  dyld                     	0x8fe1a278 _dyld_start + 0x64

[Rubycocoa-talk] Re: Newbie question

[John L. <jo...@jo...>]

On Apr 24, 2005, at 3:33 AM, Tom Counsell wrote:

> I have a feeling this is a really stupid question, but I really  
> can't see what to do, so I'd really appreciate your help:

It's not so stupid.  Xcode has some quirkiness in its interface that  
is *not* intuitive.

> Using Xcode, how can I make it so that a ruby library is copied  
> into the application resources folder, but keep the folder  
> hierarchy so that the require statements work?

You'll probably want to use a "Copy Files" build phase in Xcode.   
That will retain the hierarchy instead of flattening it.

Here's how you might do it (note that I've tested this, but just with  
a regular ObjC Cocoa project, not with a Ruby project).

1. Add your Ruby library folder to the Xcode project.  You could just  
drag it in from the Finder, or do Project > Add to Project...  Check  
the "Copy items" checkbox if desired/necessary.  Make sure you select  
the "Create Folder References" option; I couldn't get my test to work  
without this.

2. Open the Targets group, then the target for your application.   
Right-click on your application target and select Add > New Build  
Phase > New Copy Files Build Phase.  (This might look slightly  
different; I'm using Xcode 2.0.)  In the Info window, click the  
General tab and make sure Destination is set to Resources.  (I  
suppose this could be set to whatever you want; see below)

3. In the Groups & Files pane, drag the group containing your Ruby  
library to the new Copy Files build phase under your application  
target.  You should see the dot-with-horizontal-line marker; just  
make sure it's under and to the right of the Copy Files item.

4. Build your app!  If you go to the Finder, select your built app,  
right-click, and select Show Package Contents, you should be able to  
navigate into your app's Resources folder, and find your Ruby library  
with hierarchy intact.

You may need to modify $: ($LOAD_PATH) to point to the Resources  
folder; I haven't tried that part of it.  You might also consider  
either using the existing Frameworks folder instead of Resources.  I  
don't think it would make much different in the end, but is just an  
organizational thing.

--
John Labovitz
Macintosh support, research, and software development
John Labovitz Consulting, LLC
jo...@jo... |  +1 503.949.3492 | www.johnlabovitz.com/ 
consulting

[Rubycocoa-talk] Newbie question

[Tom C. <ta...@ca...>]

Hello

I have a feeling this is a really stupid question, but I really can't 
see what to do, so I'd really appreciate your help:

Using Xcode, how can I make it so that a ruby library is copied into 
the application resources folder, but keep the folder hierarchy so that 
the require statements work?

I'm trying to include a ruby library in my rubycocoa application.  It 
consists of:

syntax.rb

syntax folder
-- common.rb
-- version.rb

-- convertors folder
---- abstract.rb
---- html.rb

-- lang folder
---- ruby.rb
---- xml.rb
---- yaml.rb

I added the files to my xcode project, but when I click build and run, 
xcode seems to copy all the files across to the resources folder, but 
it puts them all in the top directory and loses all the folders:

resources folder
-- syntax.rb
-- common.rb
-- version.rb
-- abstract.rb
-- html.rb
-- ruby.rb
-- xml.rb
-- yaml.rb

This makes all the require 'syntax/common' statements and the like not 
work.

Thanks

Tom

Re: [Rubycocoa-talk] Core Data?

[mrpotatohead <mrp...@le...>]

I posted this question a while back, as DB integration is critical to
me. I however did not get a response at the time.

Have you considered using the hugely popular Ruby On Rails and its
Active Record as a database abstraction layer to an SQLite Database: See
the links:

http://wiki.rubyonrails.com/rails/show/HowToUseActiveRecordOutsideRails

http://www.rubyonrails.com/

http://wiki.rubyonrails.com/rails/show/HomePage

http://wiki.rubyonrails.com/rails/show/HowToPopulateYourDbFromScript

So Ruby performs logic , Ruby on Rails and Active Record the DB
abstraction, and RubyCocoa the GUI.

I would love to know how you go - Best of luck.

On Sat, 23 Apr 2005 11:32:21 -0700, "Don Robertson"
<box...@pa...> said:
> I know RC can use Bindings, but will it be viable to use Core Data too?
> --------
> "Who am I, that I am vying for your touch?"
> Untouchable Face, Ani Difranco
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
-- 
  mrpotatohead
  mrp...@le...

[Rubycocoa-talk] Core Data?

[Don R. <box...@pa...>]

I know RC can use Bindings, but will it be viable to use Core Data too?
--------
"Who am I, that I am vying for your touch?"
Untouchable Face, Ani Difranco

Re: [Rubycocoa-talk] RubyCocoa macosx bundle without installed ruby ?

[Jonathan P. <jp...@dc...>]

On 22 Apr 2005, at 20:18, Remo Eichenberger wrote:

> i'm very interest on this script. i'm also interest about how it 
> works. i'm very happy when you can post this :)

I've attached the script to this message.

It still needs work, but hopefully some people will find it useful and 
it can be improved.

Except from the header:

# standaloneify.rb
# Takes a built RubyCocoa app bundle (as produced by the
# Xcode/ProjectBuilder template) and copies it into a new
# app bundle that has all dependencies resolved.
#
# usage:
#   ruby standaloneify.rb -d mystandaloneprog.app mybuiltprog.app
#
# This creates a new application that should have dependencies resolved.
#
# The script attempts to identify dependencies by running the program
# without OSX.NSApplicationMain, then grabbing the list of loaded
# ruby scripts and extensions. This means that only the libraries that
# you 'require' are bundled.
#
# NOTES:
#
#  Your ruby installation MUST NOT be the standard Panther install -
#  the script depends on ruby libraries being in non-standard paths to
#  work.
#
#  I've only tested it with a DarwinPorts install of ruby 1.8.2.
#
#  Extension modules should be copied over correctly.
#
#  Ruby gems that are used are copied over in their entirety (thanks to 
some
#  ideas borrowed from rubyscript2exe)
#
#  install_name_tool is used to rewrite dyld load paths - this may not 
work
#  depending on how your libraries have been compiled. I've not had any
#  issues with it yet though.

Re: [Rubycocoa-talk] RubyCocoa macosx bundle without installed ruby ?

[kimura w. <ki...@us...>]

Hi,

>hi all ( sorry for my english)
>
>i have two questions:
>
>- is there a way to build a rubycocoa-application WITHOUT  a 
>preinstalled ruby-runtime ? i mean a static compile of the 
>ruby-runtime.

I received a patch for RubyCocoa. This patch enables RubyCocoa to 
include libruby and ruby libs.

http://beaver.net/blog/archives/2005/04/first_major_set.html

Re: [Rubycocoa-talk] RubyCocoa macosx bundle without installed ruby ?

[Remo E. <re...@pl...>]

thank you for your information.

i'm very interest on this script. i'm also interest about how it works. 
i'm very happy when you can post this :)

regards,

Remo Eichenberger

Am 22.04.2005 um 20:58 schrieb Jonathan Paisley:

>
> On 22 Apr 2005, at 19:48, Remo Eichenberger wrote:
>
>> i have two questions:
>>
>> - is there a way to build a rubycocoa-application WITHOUT  a 
>> preinstalled ruby-runtime ? i mean a static compile of the 
>> ruby-runtime.
>
> I have made a script which can build a standalone rubycocoa 
> application. It's designed to work with a non-Apple install of ruby 
> (1.8.x), and copies over all the dependent libraries and bundles, as 
> well as relevant parts of the ruby standard library into the app.
>
> If there's interest, I'll tidy it up a bit and post it to the list.
>
>> - is there a compiler or a obfuscator to build a 
>> rubycocoa-application ?
>>
>> my goal is to build a application without the distribution of the 
>> source-code :)
>
> Ultimately, because ruby is a scripting language, an end user will be 
> able to get at the source code (or close enough).
>
> With development of a ruby bytecode interpreter like YARV, this will 
> be harder, but it would still be possible to decompile back to some 
> kind of source.
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

Re: [Rubycocoa-talk] RubyCocoa macosx bundle without installed ruby ?

[Jonathan P. <jp...@dc...>]

On 22 Apr 2005, at 19:48, Remo Eichenberger wrote:

> i have two questions:
>
> - is there a way to build a rubycocoa-application WITHOUT  a 
> preinstalled ruby-runtime ? i mean a static compile of the 
> ruby-runtime.

I have made a script which can build a standalone rubycocoa 
application. It's designed to work with a non-Apple install of ruby 
(1.8.x), and copies over all the dependent libraries and bundles, as 
well as relevant parts of the ruby standard library into the app.

If there's interest, I'll tidy it up a bit and post it to the list.

> - is there a compiler or a obfuscator to build a rubycocoa-application 
> ?
>
> my goal is to build a application without the distribution of the 
> source-code :)

Ultimately, because ruby is a scripting language, an end user will be 
able to get at the source code (or close enough).

With development of a ruby bytecode interpreter like YARV, this will be 
harder, but it would still be possible to decompile back to some kind 
of source.