[Code] Ruby LOAD PATHs script (Win32) : ver 3.0.1

Dan Rathbun

This looks handy for testing out full Ruby with SU.

That IS the idea.

Instead of copying standard library files by ones or twos into some plugin folder (which may differ in version to the interpreter your running with Sketchup,) the idea is to leave those library files where they are (so they can be managed and maintaned with RubyGems.)

This script then allows you to just load them from your (or a user's,) full install folders. That way we won't have old versions of standard library files, peppered amonst our plugin subfolders.

The next step in revising this script is to allow for alternate install locations, if a user is using concurrent version managment software (pik on Win32, RVM on OSX.) I'll have to add a "base" variable that replaces the "C:/" in the pre variable with "#{ENV['USERPROFILE'}/.pik/"] (Win32) or "#{ENV['HOME'}/.rvm/"] (OSX). And perhaps a custom base location var.

Dan Rathbun

replying to:
Re: Clients <--> Server Communication (Sockets?)

@mtalbott said:

Jim, that's Interesting. At first I couldn't replicate your require 'socket' result but then I tried in Sketchup 8 and it worked. "RUBY_VERSION" in SU7 says "1.8.0" and in SU8 "1.8.6" Is that why it doesn't work in 7?
No. It's because you used an absolute path to the socket.so file, and your system was able to find it.

@mtalbott said:

i386-mingW32 vs i386-mswin32 is beyond me at the moment.
RUBY_PLATFORM is the constant, set by the compiler that complied the Ruby that is running. In Sketchup, open the Console and type RUBY_PLATFORM, do the same (outside Sketchup,) in IRB for one of the Standard Ruby installs... you'll see the value is different.
i386-mswin32 is compiled with MS Visual Studio
i386-mingW32 is compiled with the minGW compiler.
It's not just the interpreter DLL that is compiled, all of the .so (source object,) files in the libraries are also.

@mtalbott said:

I can say however, that I use your !loadpaths.rb which adds the i386-mswin32 directory to the $LOAD_PATH ...
It actually adds the ruby lib folder and the platform subfolder of the ruby lib folder to the $LOAD_PATH array, based upon the values of the RUBY_PLATFORM constant, the RUBY_VERSION constant of the interpreter that is loaded; plus a few tweeker variables, to guess at what the Standard Ruby paths SHOULD be.
The script is quick and dirty.. and does not have error checking, and assumes the user knows how to use a full Ruby install, and installed it correctly.
I am working on a more advanced version, that will be cross-platform, and be compatible with multiple Ruby installs managed by a RVM utility.

@mtalbott said:

... and when I "require 'C:/ruby186/lib/ruby/1.8/i386-mingw32/socket'" it returns true.
It returns true (again,) because you used an absolute path, and did NOT rely upon the $LOAD_PATH array. (You should read the description of the Kernel.require method.)

@mtalbott said:

Are you recommending that I uninstall my current ruby build and get the mswin32 version?
You should endeavour to use compiled libraries that match the interpreter that is loaded, with respect to RUBY_VERSION, RUBY_PATCHLEVEL and that are compiled by the same compiler.
How many Ruby versions you have, and where you put them depends on what you do with them. (There are a handful of environment vars that need to change, depending on which version you have in use.)
It's easier to manage multiple installs if you use an RVM (Ruby Version Managment,) utility.

I have come to believe that the Ruby Libraries used with Sketchup should be separate from those used as a "System" Ruby (which a user might use for Ruby on Rails, or major projects, or with other Applications.)
This will allow the "Sketchup Ruby Install" to be tweeked for use with Sketchup, while leaving the System Ruby Install(s) alone, or to be tweeked for Rails, or whatever.
For instance... I have a complete Ruby (manual) install beneath my Sketchup application folder.

@mtalbott said:

Should I stick with 1.8.6?
Well ...

Sketchup will not load 1.9.x, so thats out.
Ruby ver 1.8.0 thru 1.8.5 (all patchlevels,) are obsolete* It may be that v1.8.7 header files did not change (from 1.8.6,) as loading up to the lastest patch (v1.8.7p330) seems to work at first blush.* Since SU 8 is complied with MS Visual Studio, and it's Ruby API extensions are also, AND in doing so, Google had to "include" ruby header files from 1.8.6 (p287 to be exact,) I would say, it's safest to use i386-mswin32 compiled binaries in the 1.8.6 branch, of no less than patchlevel 287. If you are writing plugins that others will use, you might as well, use the version they are going to be running your plugin on.
Now.. there are certain areas (speed, stability, threads) that minGW compiled Ruby is supposed to be better than mswin32 Ruby. I tried loading a mingw Ruby interpreter and Sketchup didn't have a problem with it. The only way to tell is to use it and exercise it under sketchup and see if there are problems.

For SU 7.x, I've been running it with Ruby 1.8.6-p111 or higher since the second day I had it. I always encourage ppl to replace the SU7 DLL with a Ruby 1.8.6 (I posted them for download in the Ruby Resources topic, with Instructions.)

mtalbott

Wow! So helpful! I'm going to have to absorb this all for a little while. Thanks.

psylus

Hello,

I am trying to write a plugin for sketchup 8 using rubygems. I gave up trying on mac and now I'm trying on windows.
I had the loadpaths script on sketchup's plugins directory. my ruby directory is C:\Ruby187, I forgot to change ruby to Ruby inside the script.

The weird thing is that even when I remove from the directory the plugin I am trying to load, I still get load error messages about it and the mistaken load path remains when I remove the loadpaths script. I tried reinstalling sketchup, delete everything from win registry, app data folders, environment variables and I still get the same error message about loading the plugin! Where is all this info stored and I can not get rid of it?

About the initial load error now, whenever I uncomment the #$LOAD_PATH << "#{pre}/site_ruby/#{ver}" line
(the directory containing the rubygems file among others), sketchup crashes during launch.

I would appreciate your help, thank you in advance!

Dan Rathbun

@psylus said:

... my ruby directory is C:\Ruby187, I forgot to change ruby to Ruby inside the script.

Windows is a case-insenstive OS. It doesn't matter whther the 'R' in Ruby is upcase or downcase.

However, if you are going to use v1.8.7 (at some patch level,) Ruby with Sketchup, you should be sure that Sketchup loads the same version and patchlevel interpreter DLL.
See http://forums.sketchucation.com/viewtopic.php?f=180&t=10142&p=298780#p276047 for instructions on Windows, for how to make Sketchup load another Ruby version.

Dan Rathbun

@psylus said:

I am trying to write a plugin for sketchup 8 using rubygems.

...

About the initial load error now, whenever I uncomment the #$LOAD_PATH << "#{pre}/site_ruby/#{ver}" line
(the directory containing the rubygems file among others), sketchup crashes during launch.

The topic of RubyGems under Sketchup embedded Ruby, belongs in the following forum thread:
Getting SketchUp to play nicely with RubyGems?

... I begin answering in that thread, here: http://forums.sketchucation.com/viewtopic.php?f=180&t=29544&p=342469#p342469

Dan Rathbun

@psylus said:

The weird thing is that even when I remove from the directory the plugin I am trying to load, I still get load error messages about it and the mistaken load path remains when I remove the loadpaths script. I tried reinstalling sketchup, delete everything from win registry, app data folders, environment variables and I still get the same error message about loading the plugin! Where is all this info stored and I can not get rid of it?

We cannot help you unless you post the exact LoadError message. (Which will tell us the name of the script that is still trying to load the removed plugin.)

26delta

Message from 000_AdditionalPluginFolders

2 ERROR(S): The following plugins ha errors and may not be fully loaded

PLUGIN: win32api.so
FOLDER: C:\Program Files\Google\Google SketchUp 8\Plugins
ERROR: 127: The specified procedure could not be found - Init_win32api
C:\Program Files\Google\Google SketchUp 8\Plugins\win32api.so

26delta

@dan rathbun said:

The init function must is capitalized the same way the filename is.

Therefor you MUST call require with the so file cap'd as it is in a directory listing:

require("Win32API") # not "win32API" nor "win32api"

This creates an interesting problem. The error was introduced by the Rayelectron package which works with a file named "win32api.so". Somehow, in all the confusion, my Win32API.so file got overwritten by win32api.so. The files are identical, but differently named.

Dan Rathbun

The init function name is capitalized the same way the filename is.

Therefor you MUST call require with the so file cap'd as it is in a directory listing:

require("Win32API") # not "win32API" nor "win32api"

Dan Rathbun

@26delta said:

This creates an interesting problem. The error was introduced by the Rayelectron package which works with a file named "win32api.so". Somehow, in all the confusion, my Win32API.so file got overwritten by win32api.so. The files are identical, but differently named.

Obviously the problem was created by whomever in the "Rayelectron" project, decided it would be a good idea (NOT!) to create an extension with the same name as a standard Ruby library source object file. (Because most Operating Systems are case-aware, but case tolerant... the OS will treat the filename the same, no matter how a command or shortcut may have the text 'cased'.)

BUT.. internally, the require method (for some reason...,) will only load a file if it matches casewise the part of function name following "Init_"

I always wondered why the programmers did not just copy the function a few times and rename it, thus:

 // C
function Init_Win32API(){
  init();
}

function Init_WIN32API(){
  init();
}

function Init_win32API(){
  init();
}

function Init_win32api(){
  init();
}

The only good thing from this is that a hacker/pirate cannot "steal" (violate copyright,) an so file by renaming it.

~