Migrating plugins to SketchUp 2013

RichMorin

The SketchUp team says that upgrading the version of Ruby will be a strong priority for "SketchUp 2013". The current version of Ruby (outside of SketchUp) is 1.9.3, and 2.0.0 is scheduled for release in early 2013. However, moving to either of these versions would break large numbers of plugins.

My hope is that SketchUp 2013 will contain Ruby 1.8.7, with a substantially complete copy of the Standard Library. Ruby 1.8.7 introduces a number of 1.9's features, but it is (mostly) backward compatible with 1.8.6. So, we'd have a year or so to try things out, develop and implement migration strategies, etc.

In any case, plugin developers would be well advised to start learning about the changes in Ruby 1.9, thinking about how to create plugins that will work in either 1.8 and 1.9, etc. In support of this, I have created a couple of web pages that I hope will be useful. Comments and suggestions are earnestly solicited...

http://wiki.cfcl.com/bin/view/SketchUp/Cookbook/RE_Migration - Ruby Migration

http://wiki.cfcl.com/bin/view/SketchUp/Cookbook/RE_19_Changes - Ruby 1.9 Changes

-r

Dan Rathbun

My two cents worth... Mac users / developers are often blind to the problems that Windows users / developers have with unicode support, because it often "just works", ie with filepath strings.

AFAIK, unicode support in Ruby is built-in from v1.9+, so many of us who primarily use and develop on Windows will be voting for some stable Ruby release in the 1.9 trunk. (It's also much faster than the versions in the 1.8 trunk, at least on Windows!)

That is not to say that I haven't already requested that SketchUp be Ruby version agile (allowing the user or developer to choose what installed Ruby version to have SketchUp load.)
This will of course mean that plugin developers will need to check RUBY_VERSION before loading their plugin, to see if the minimum AND / OR maxium Ruby version(s) required by the plugin are met. If not, the plugin should not load, and inform the user somehow (load log, etc.)

Aerilius

@unknownuser said:

However, it might be possible to capture this usage dynamically (eg, by tracking calls to String#to_a).

Could we create/use a compatibility checking tool to test plugins automatically where they use changed methods? (by aliasing these methods or using set_trace_func).
Or maybe such a script exists already?

(As a side note: I haven't used set_trace_func yet, but it sounds like we could also find scripts that mess with base classes?)

Dan Rathbun

@Aerilius: set_trace_func slows things way down, so it should only be used during a check of a specific file.

And we have discussed a script checker in another thread, but in the context of "do" and "dont", and flagging problem code, etc.

danielbowring

If changes are going to be made to the ruby package, I'd hope that:

Newer ruby version (1.9+)
Always use built-in package (same ruby on windows, mac)
Full library, not core (No external ruby installation needed)
rubygem support, including the ability to add new gems (possibly confirm with user first, eg Sketchup::Gem.install(name) shows a confirmation dialog to the user)
Better console (sketchup-developer-tools is headed in the right direction, but we still can't capture STDERR)

Dan Rathbun

Nice start on these lists! They will be sorely needed.

(I wish we had the same sort of list to identify the differences between SU 1.8.5-p0 Ruby and v1.8.6-p287 Ruby, as a guide for Mac vs Win scripting, NOW.)

Ruby 1.9 Changes : Hashes : Commas are not allowed as key/value separators
They NEVER WERE allowed in { ... } literals to separate a key from a value, BUT ARE required to separate key/value pairs from one another.
They ARE allowed in the Hash[] class method, to separate keys from values, because they are arguments and commas separate arguments in argument lists.
So, I see this one as a non-issue.
EDIT(add): It occurs to me Rich, you are confounding Javascript Object literals with Ruby Hash literals. They are quite close in syntax, which makes them realitely easy to convert.
See this topic: JSON in Ruby

thomthom

@unknownuser said:

If changes are going to be made to the ruby package, I'd hope that:

Newer ruby version (1.9+)

Always use built-in package (same ruby on windows, mac)

Full library, not core (No external ruby installation needed)

rubygem support, including the ability to add new gems (possibly confirm with user first, eg Sketchup::Gem.install(name) shows a confirmation dialog to the user)

Better console (sketchup-developer-tools is headed in the right direction, but we still can't capture STDERR)

+1

1.9 is needed in order to get Unicode support for file handling under Windows.
It will break stuff - but, 1.8 is an aged product.
The Standard Library has conflicts with the Set class that ships with SketchUp - but I see it as not a big problem if they upgrade to v1.9 or 2.0 - if you're going to break a little bit you might as well break it big. Sort things out.

I hope version 2.0 is done in time for the eventual upgrade of the SketchUp Ruby core. Just so we won't be stuck in the same situation where we're using 1.9 for many years while the rest of the world is using 2.0.

Though, I wouldn't be surprised if SketchUp 2013 didn't upgrade the Ruby core - as I can see it could a big task to get everything working right.

RichMorin

@dan rathbun said:

They NEVER WERE allowed in { ... } literals to separate a key from a value, BUT ARE required to separate key/value pairs from one another.

Ruby 1.8.7 (on Mac OS X Snow Leopard) accepts commas as key/value separators:


$ irb --simple-prompt
>> {1,2,3,4}
=> {1=>2, 3=>4}
>> RUBY_VERSION
=> "1.8.7"

fredo6

Trimble should release an early pilot version "Developer only" with the new Ruby interpretor (whether 1.8.7 or 1.9.3), maybe on the same base as Sketchup 8 M4.

This will give developers a chance to test and find ways to manage compatibility.

Reading the documentation that Rich kindly pointed to, I found on my side 2 potential issues:

%(#0040FF)[1) Instance variables are explicitly initialized to false
An instance variable which previously wasn’t initialized is now explicitly initialized to false.]

I sometimes use a test if @var precisely to check if the variable has been initialized or not. However, I would need to check if I don't use if @var == nil in some instances

%(#0040FF)[2) Array#pack and String.unpack

In Ruby 1.8, Array#pack generates ASCII byte codes:

s = (0..4).to_a.pack("V*")
=> "\000\000\000\000\001\000\000\000\002\000\000\000\003\000\000\000\004\000\000\000"

In Ruby 1.9, it generates a string of Unicode characters:

s = (0..4).to_a.pack("V*")
=> "\x00\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00\x04\x00\x00\x00"]

I only use the codes U and C. So I don't know if there is an impact actually.

Of course, there may be side-effects and this is why a long period of testing would be required so that the community of developer can popularize the best ways to keep compatibility.

Fredo

Dan Rathbun

@unknownuser said:

Trimble should release an early pilot version "Developer only" with the new Ruby interpretor (whether 1.8.7 ...), maybe on the same base as Sketchup 8 M4.

This will give developers a chance to test and find ways to manage compatibility.

I already do this on MS Windows, it is quite easy. No need to wait for Trimble to test v1.8.7.

See: Ruby Interpreter DLLs (Win32)

Unfortunately, because SketchUp currently, during startup, calls C-side Ruby encoding functions, that do not exist in v1.9+, nor have any aliases (why didn't the Ruby Core guys alias the old function names to the new function names?,) we cannot test SketchUp with Ruby v1.9+, unless we add aliases to the source, and compile a special edition just for SketchUp.

Dan Rathbun

@richmorin said:

@dan rathbun said:

They NEVER WERE allowed in { ... } literals to separate a key from a value, BUT ARE required to separate key/value pairs from one another.

Ruby 1.8.7 (on Mac OS X Snow Leopard) accepts commas as key/value separators:

You are correct, I stand corrected.

It also works in Ruby v1.8.6-p287.

It was I, that never noticed the following sentence:
@unknownuser said:

**]](http://www.ruby-doc.org/core-1.8.6/Hash.html#method-c-5B-5D)":2ll8d5ft]Equivalent to the literal { key, value, ... }.

.. so, I never used that literal syntax. I use Hash[] when I wanted to list a hash separated with commas.

Having some coffee.. and thinking about it, ... I makes sense. The interpreter must call some method, with literal arguments.

This indicates that the interpreter does something similar to this (but on the C-side):
literal = "{1,2,3,4}" Hash[ *(literal.gsub(/\{|\}/,'').split(',').map{|e|eval(e)}) ]
(You can see the C source if you click on the definition in the online doc.)

More important to me, would be if v1.9+ actually changed the **Hash::[]** class constructor method.
But they did not. It still accepts comma separated arguments.
They did add allowing key value pairs to be passed as 2 element Array arguments, which is nice.
see: v1.9 : Hash::[]

Sorry for MY confusion, Rich.

Trogluddite

Many thanks for your guide, Rich.
Ironically, it has been most enlightening for some issues I've been having when using the current SU API, as I've been using Ruby 1.9.3 elsewhere for a while.

RichMorin

@dan rathbun said:

Sorry for MY confusion, Rich.

No problem! Catching Dan Rathbun in an error is quite a triumph.

More generally, I'm quite sure that my pages have both errors and omissions; I just don't know what they are. If you (or anyone else) can tell me about problems, I'd be most pleased.

-r

danielbowring

Epic bump, but is there any news on this? Was upgrading the installation ruby put on the backburner? Should we still be expecting this sometime in the future (or a complete library at least)?

To me at least, this seems like a really important feature - plugins and the community around them are a powerful part of sketchup.