rubycocoa-talk

[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] 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?

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 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 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

[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

[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

[Mark H. <di...@ma...>]

On May 25, 2005, at 3:29 AM, Jonathan Paisley wrote:

>
> 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.

mark@eMac% l /Library/Frameworks
total 16
drwxrwxr-x    6 root  admin   204 May 25 00:23 .
drwxrwxr-t   47 root  admin  1598 May 25 00:23 ..
-rw-rw-r--    1 mark  admin  6148 May 24 23:47 .DS_Store
drwxr-xr-x    7 mark  admin   238 May 25 00:08 Readline.framework
drwxr-xr-x    6 mark  admin   204 May 25 00:25 Ruby.framework
drwxrwxr-x    6 root  admin   204 May 12 21:33 StuffIt.framework
mark@eMac% ruby -v -e'puts RUBY_FRAMEWORK_VERSION'
ruby 1.8.2 (2004-12-25) [powerpc-darwin8.0.0]
0.5
mark@eMac% ls -la `where ruby`
lrwxr-xr-x   1 root  wheel  65 May 25 00:42 /usr/bin/ruby -> /Library/ 
Frameworks/Ruby.framework/Versions/Current/Commands/ruby

> 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.

It's a little slow going, but it's being tackled. It's at a point now  
where I'm eating my own dog food, and it's almost tasty. :) The focus  
is on maximum containment, with no files being external to the  
framework and support dirs (/Library/Frameworks/Ruby.framework and / 
Library/Ruby). Eventually, Drag and drop installation will be  
possible, and there will be a gui app included to do any configuration.

Still, Dave, it would be a good idea to get used to the command-line  
voodoo. All it takes is practice, and you will gain a much wider  
understanding of how things work under the hood of OSX. I agree that  
we need to move towards self-contained drag-and-drop installable  
frameworks and applications, but I don't see Apple getting to that  
point any time soon. They make small advances with each OS release,  
but I shudder to think of the development costs that would be  
required to get it all done at once (and for only minimal return on  
investment). At the moment, though, almost all the core OS  
functionality is based around /bin /var /etc and /dev.

Anyway, I couldn't resist plugging the framework into this thread. :)  
It's almost ready for a preview release, contact me off-list if you  
want to test-drive it when it's ready.

cheers,
Mark

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

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

On May 25, 2005, at 8:48 AM, Mark Hubbart wrote:

> mark@eMac% l /Library/Frameworks
> ...
> drwxr-xr-x    6 mark  admin   204 May 25 00:25 Ruby.framework
> mark@eMac% ruby -v -e'puts RUBY_FRAMEWORK_VERSION'
> ruby 1.8.2 (2004-12-25) [powerpc-darwin8.0.0]
> 0.5
> mark@eMac% ls -la `where ruby`
> lrwxr-xr-x   1 root  wheel  65 May 25 00:42 /usr/bin/ruby -> 
> /Library/Frameworks/Ruby.framework/Versions/Current/Commands/ruby

[squinting] I think this is telling me that Mark's 'ruby' command lurks 
in a framework. And that he's running Tiger. K00l.

>  It's at a point now where I'm eating my own dog food, and it's almost 
> tasty. :)

[shakes head] I am SO glad there are people out there who think that 
sort of thing is fun. :)

> Still, Dave, it would be a good idea to get used to the command-line 
> voodoo.

Aww, c'mon. I've replaced my /usr/bin/ruby with a link to 1.8.2. I've 
installed TeX, and installed fonts into it (shudder). I've redefined 
"ls -la" as "dir". I know where my mach kernel is,  my PATH, and my 
.login file. I'm *used* to command-line voodoo. I just don't *like* it. 
:) I spend way too much time trying to guess how to make the 'man' 
command cough up useful answers. [I'd love to spend a little time in a 
small room with a baseball bat and the guy who thought that making case 
significant was a good idea.]

There's a Terminal window open most of the time. But the less I have to 
use it, the happier I am, as a general rule. TextWrangler good, pico 
bad (do NOT get me started on Emacs or vi. I have not the words for my 
loathing). Webmin good, apachectl/postfix/rndc bad. (I didn't even know 
there WAS an rndc until I did 'man named' for this message. 
Are-en-dee-cee, for pete's sake???) DiskUtility fabulous, 
diskutil/pdisk/fdisk/bless/whatever frightening.

I hug my perky working (I hope!) RubyCocoa, so that now my Ruby 
programs can also eschew the command line. smilesmilesmilesmilesmile.

I am often mistaken for a programmer. I'm actually a hard-core 
applications person. I make my programs work really hard. (I've 
applescripted Freehand to load PostScript files that I'm writing to the 
drive as text. Macromedia tech support didn't even know that FreeHand 
could *be* applescripted. No, not with the UI tools, either.) I program 
only to make the applications that I need that don't yet exist. (cf. 
http://grandfenwick.net/dave/applescripts especially Sort&File, iTunes 
Voice Control, and Chatelaine. Font Undulator isn't listed there, but 
it's a drag & drop window that takes just about any random font file 
(Suitcase, LWFN, .pfb, .ttf, .bin) and hammers it into a .dfont or 
.otf.)

I need to speed up my Mail archiving application, and make a game show 
display board and a to-do list manager (and I've looked at every 
existing one I could find, and only TinderBox came close to doing what 
I needed. But it's not a to do list manager, it's a programming 
environment. So I'm using Ruby instead).

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

[Mark H. <di...@ma...>]

On May 25, 2005, at 12:33 PM, Dave Howell wrote:

>
> On May 25, 2005, at 8:48 AM, Mark Hubbart wrote:
>
>
>> mark@eMac% l /Library/Frameworks
>> ...
>> drwxr-xr-x    6 mark  admin   204 May 25 00:25 Ruby.framework
>> mark@eMac% ruby -v -e'puts RUBY_FRAMEWORK_VERSION'
>> ruby 1.8.2 (2004-12-25) [powerpc-darwin8.0.0]
>> 0.5
>> mark@eMac% ls -la `where ruby`
>> lrwxr-xr-x   1 root  wheel  65 May 25 00:42 /usr/bin/ruby -> / 
>> Library/Frameworks/Ruby.framework/Versions/Current/Commands/ruby
>>
>
> [squinting] I think this is telling me that Mark's 'ruby' command  
> lurks in a framework. And that he's running Tiger. K00l.

The "lurking in a framework" is the part I was getting at. After your  
rant about (among other things) self-containedness and drag and drop  
installation, I thought you might find it interesting, since it  
solves those problems in the apple-preferred way.

>>  It's at a point now where I'm eating my own dog food, and it's  
>> almost tasty. :)
>>
>
> [shakes head] I am SO glad there are people out there who think  
> that sort of thing is fun. :)

:) I guess it's fun to make things work properly, though fun isn't  
the reason for this. Frameworks support being embedded in  
applications.  If you try to distribute an application that you  
create that was made with your non-apple ruby installation, it will  
likely not run until the users upgrade their ruby to be the same as  
yours. Which sucks. With a framework, there are fewer worries.

>> Still, Dave, it would be a good idea to get used to the command- 
>> line voodoo.
>>
>
> Aww, c'mon. I've replaced my /usr/bin/ruby with a link to 1.8.2.  
> I've installed TeX, and installed fonts into it (shudder). I've  
> redefined "ls -la" as "dir". I know where my mach kernel is,  my  
> PATH, and my .login file. I'm *used* to command-line voodoo. I just  
> don't *like* it. :) I spend way too much time trying to guess how  
> to make the 'man' command cough up useful answers. [I'd love to  
> spend a little time in a small room with a baseball bat and the guy  
> who thought that making case significant was a good idea.]
>
> There's a Terminal window open most of the time. But the less I  
> have to use it, the happier I am, as a general rule. TextWrangler  
> good, pico bad (do NOT get me started on Emacs or vi. I have not  
> the words for my loathing). Webmin good, apachectl/postfix/rndc  
> bad. (I didn't even know there WAS an rndc until I did 'man named'  
> for this message. Are-en-dee-cee, for pete's sake???) DiskUtility  
> fabulous, diskutil/pdisk/fdisk/bless/whatever frightening.
>
> I hug my perky working (I hope!) RubyCocoa, so that now my Ruby  
> programs can also eschew the command line. smilesmilesmilesmilesmile.
>
> I am often mistaken for a programmer. I'm actually a hard-core  
> applications person. I make my programs work really hard. (I've  
> applescripted Freehand to load PostScript files that I'm writing to  
> the drive as text. Macromedia tech support didn't even know that  
> FreeHand could *be* applescripted. No, not with the UI tools,  
> either.) I program only to make the applications that I need that  
> don't yet exist. (cf. http://grandfenwick.net/dave/applescripts  
> especially Sort&File, iTunes Voice Control, and Chatelaine. Font  
> Undulator isn't listed there, but it's a drag & drop window that  
> takes just about any random font file (Suitcase,  
> LWFN, .pfb, .ttf, .bin) and hammers it into a .dfont or .otf.)
>
> I need to speed up my Mail archiving application, and make a game  
> show display board and a to-do list manager (and I've looked at  
> every existing one I could find, and only TinderBox came close to  
> doing what I needed. But it's not a to do list manager, it's a  
> programming environment. So I'm using Ruby instead).

If you're programming in AppleScript and Ruby, IMHO, you're a  
programmer :) Maybe not by trade, but by habit -- like a lot of  
programmers, myself included.

Anyway, I was just offering another perspective. I learned to like  
the command line, though I started out hating to use it. Once I got  
familiar with man and apropos, learned the terminology, and got  
practice, I realized that it's easier to use it than the gui in many  
cases. However, YMMV, so use what works best for you.

cheers,
Mark

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

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

On May 25, 2005, at 1:21 PM, Mark Hubbart wrote:

> The "lurking in a framework" is the part I was getting at.

That's what I figured.

> :) I guess it's fun to make things work properly, though fun isn't the 
> reason for this. Frameworks support being embedded in applications.  
> If you try to distribute an application that you create that was made 
> with your non-apple ruby installation, it will likely not run until 
> the users upgrade their ruby to be the same as yours. Which sucks. 
> With a framework, there are fewer worries.

Oo! Once you're framework is done, then I can compile a Ruby 
application and it will actually be a Ruby application, and not 1/3 of 
a program that breaks on anybody's system that doesn't have necessary 
(but invisible!!) Ruby files?

I wholeheartedly support efforts to enable XCode to make programs that 
actually work right. :)

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

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

On 25 May 2005, at 23:14, Dave Howell wrote:


> Oo! Once you're framework is done, then I can compile a Ruby  
> application and it will actually be a Ruby application, and not 1/3  
> of a program that breaks on anybody's system that doesn't have  
> necessary (but invisible!!) Ruby files?
>

I posted a script to this list about a month ago called  
'standaloneify.rb'. I'm reposting it again now.

It takes a RubyCocoa application you've built with Xcode and removes  
any external dependencies. I didn't hear back from anyone about it,  
so as far as I know it just "works for me".

Excerpt 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] Install failing, at wit's end

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

On May 25, 2005, at 3:29 AM, Jonathan Paisley wrote:

> 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.

I know. How painfully I know. Sigh.

> 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 know why it does that. The nastiness is that it makes debugging 
vastly worse, when what happens on "my" command line is often but not 
always the same as what happens at AppleScript's command line. Oh, 
well. (And finding the 'whereis' command frequently refusing to answer 
the question doesn't help. Grr.)

> 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.

Note that I agreed with this! I am, however, quite comforted that you 
seem to agree, generally, with the observation that it isn't the Mac 
way, even if it is a bit soon to expect it to be so. :)

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

[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

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

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

> 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.
>

Although that VERSION says 0.4.1, it isn't the 0.4.1 release. You've  
checked out an old version of the code that was used for working on  
initial Panther support.

The VERSION file for 0.4.1 release looks like this:

VERSION = "0.4.1"
STAGE = ""
RELEASE_DATE = "2005-03-25"

Probably easiest to go with the 0.4.1 source tar:

http://prdownloads.sourceforge.net/rubycocoa/rubycocoa-0.4.1.tgz? 
download

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

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

On May 25, 2005, at 3:37 AM, Jonathan Paisley wrote:

>
> Although that VERSION says 0.4.1, it isn't the 0.4.1 release.

[bangs head against wall]

Oh. My goodness.

All right, let's start by installing a different 0.4.1........

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

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

On May 25, 2005, at 11:22 AM, Dave Howell wrote:

>
> On May 25, 2005, at 3:37 AM, Jonathan Paisley wrote:
>
>>
>> Although that VERSION says 0.4.1, it isn't the 0.4.1 release.
>
> [bangs head against wall]
>
> Oh. My goodness.
>
> All right, let's start by installing a different 0.4.1........

Imagine!

It works.

Hallelujah, the program actually opened a window without error. I'm 
staring at a window.

[I do a little jig of joy.]

The insurmountable obstacle preventing me from completing my headlong 
flight from AppleScript has fallen. On Dasher, on Dancer, on prntcer, 
on Bixen! On cron-et, on Queue-pid, on python-cer, on bzip-sen!