Sketchup class load method bug?

Hi Guys,

I believe there may be a bug (or incorrect implementation) with the Sketchup class load method. My understanding of the Sketchup class load method is that it is modeled after the Ruby Kernel load method but designed to handle scrambled files (.rbs) as well as non-scrambled files (.rb). The problem is that it doesn’t seem to behave the same in that the Kernel.load method will load a .rb file even if it is already loaded - with the appropriate warnings - wereas the Sketchup.load method does not; even when executed from the Ruby console.

For example:

Kernel.load ‘cabwriter_factory_settings.rb’ results in

C:/Users/Joe/AppData/Roaming/SketchUp/SketchUp 2015/SketchUp/Plugins/cabwriter_factory_settings.rb:17: warning: already initialized constant CabWriterFactoryInitialize::NEW_PROJECT
C:/Users/Joe/AppData/Roaming/SketchUp/SketchUp 2015/SketchUp/Plugins/cabwriter_factory_settings.rb:17: warning: previous definition of NEW_PROJECT was here
true

Whereas Sketchup.load ‘cabwriter_factory_settings’ results in

false

Am I missing something or is this a bug?

Joe…

load "some_text_file_in_the_load_path"

always returns true unless there is an error.

require "some_text_file_in_the_load_path"

only returns true if that file has never been loaded before during that session.

Sketchup’s own require and load are designed to work with text files [typically RB files] OR its specialized compiled RBS files,
Oddly Sketchup::load is actually an alias of Sketchup::require - so both of them will return false if the file has been loaded before.
So when testing use ‘load’ instead !
Compile the RB to RBS if desired and use Sketchup’s method to load it - only when you’ve debugged the code…

Thanks for the response TIG. But that is really too bad that the implementation is an alias. There are good reasons to reload a file in debugged and distributed code using RBS. I’ll have to find a work around.

Thanks again,
Joe…

There is a simple way - work with an .rb and use load "xxxx.rb" - when it works compile it and change your loader rb to use rbs…

Something like this ?

def reload(path)
  pos = nil
  $".each_with_index{|p,i| break pos = i if p =~ /(#{path})\.(rb|rbs)\z/i }
  if pos
    $".delete_at(pos)
    Sketchup::require(path)
  end
end
1 Like

Dan,

That is exactly the type of work around I need. Thanks,

Joe…

Yes, annoyingly Sketchup::load is an alias of Sketchup::require. I don’t know why it originally was implemented like that - that’s been there since the beginning.
I’m wondering if anyone is actually using Sketchup::load in production - I hope not, because then it’d be impossible to adjust this method without breaking anything.

Another pet peev of mine in regard to these methods is that they don’t raise Ruby errors - they simply output them to the console directly. That one is more likely to break extensions if we tried to change it… :confused:

I’ve used something similar to what Dan posted in my development environment to reload RBS - removing the file from the list of loaded features.

These are the kind of things I’ve been wanting to get a GitHub repo started for - small snippet like this.

No, it’s not impossible. Just fix it and let the chips fall where they may. I would suspect that it is only being used like require anyway (sense that is the way it works.)

What I mean is, it’s most likely being used during the startup cycle, where the scripts have not yet been loaded anyway.

Add to that, the fact we’ve gotten most coders to use conditional blocks around code that should only run once. (ie, adding menu items, etc.)

So the impact will be minimal.

With the release of Ruby 2.2, refinements are no longer experimental.

I plan on re-writing what I have in SAE as a refinement library, then adding to it.

So coders would just require the lib, and then “use” it, ie:

require "lib/SAE"
using "SAE"

P.S.: “SAE” is an acronym for SketchUp API Enhancements.

But I think as it is now, it’s on the SketchUp Team acct on BitBucket.

I agree with Dan. How people are using poorly implemented methods shouldn’t stand in the way of fixing them anymore than it should from transitioning from Ruby 1.8 to 2.0. Progress is a good thing.

Dan, are you implying that SketchUp now supports version 2.2 of Ruby? Or will shortly?

Joe…

No need to imply anything.

Maintenance of Ruby 2.0.0 will end on February 24, 2016.
The last ordinal release (p643) for Ruby 2.0.0 was released on Feb 24th, last.
It is now in Security maintenance phase, until next Feb 24, 2016.
See: https://www.ruby-lang.org/en/news/2015/02/25/ruby-2-0-0-p643-is-released/

In fact SketchUp’s Ruby (p247) is already behind those patch levels that have been released by the Ruby Core Team. (p645)

Thomas has filed some bugs with the Ruby Core Team, and at least one has been fixed but in the newer versions, and was not backported to 2.0.0, before it went into security maintenance phase. (So it just will not likely be happening.)

Version 2.2.x is the current official release for the Ruby programming language.

It does not make sense to release another version of SketchUp with an outdated version of Ruby that is beyond end of life.


FYI:

Let me be more specific as what my statement was aimed at.

Thomas and I have had discussions in the past as to whether or not refinements should be used with SketchUp plugins. Thomas had stated that he was going to avoid their use while they were considered “experimental”. Changes were made in the 2.1 branch, and they became more stable. With the 2.2 branch they added the feature that they can be turned on for a namespace, ie a module or class block, instead just for the toplevel in a script file.

So my intent was aimed at the the use of refinements for shared API enhancements, more so than the lagging version issue. (But I do wish SU2015 had been updated to Ruby 2.2)