Wish List - Ruby interpreter and libraries
-
Here's another topical breakout from my "SketchUp API Wish List" post:
http://forums.sketchucation.com/viewtopic.php?f=180&t=44949
SketchUp 8 uses Ruby 1.8.6 as its embedded Ruby interpreter. As in previous releases, library support is limited: only a subset of the "standard library" is included and adding RubyGems (etc) is left to the developer.
Although there is nothing particularly wrong with version 1.8.6, the Ruby community has moved on (the current version is 1.9.3). This poses several problems for SketchUp plugin developers:
- Gem developers may not maintain 1.8.6 compatibility.
- Interpreter bugs in MRI 1.8.6 may not be fixed.
- MRI 1.8.6 is significantly slower than later versions.
- Plugin developers must track two Ruby dialects.
- Ruby documentation (eg, web sites) may ignore 1.8.6.
Options
Fortunately, none of these problems are urgent; better yet, a short-term "fix" is available. If SketchUp 9 were to move to Ruby 1.8.7, existing plugins would continue to work, but developers could start using some of the new methods and syntax. The backports library could also be included, providing some 1.9.x methods.
Although this would provide some breathing room, it's clear that SketchUp will need to move on at some point. Although there are several interesting possibilities, only a couple (MRI 2.x, mruby) seem particularly likely.
MRI 2.0 should be released in the next year or so. It will be very similar to 1.9.x, but it is expected to be the basis for ongoing Ruby development. So, some 2.x release would be a logical choice for a stable plugin environment.
However, mruby offers another interesting possibility. As an interpreter which is designed to be modular and embedded, it might be a better fit for SketchUp's use than a hacked version of a "normal" interpreter.
I'm hoping that the SketchUp team will experiment with both MRI 2.x and mruby, determining which gives them the best balance of flexibility, performance, stability, etc. At the same time, they could address the packaging and namespacing issues I discussed previously. Then, in (say) SketchUp 10, they could give us a new, shiny plugin environment!
Resources
- backports - https://github.com/marcandre/backports
- MRI 2.x - http://www.rubyinside.com/ruby-2-0-implementation-work-begins-what-is-ruby-2-0-and-whats-new-5515.html
- mruby - http://matt.aimonetti.net/posts/2012/04/25/getting-started-with-mruby/
- mruby - https://github.com/mruby/mruby
- Ruby Gems - http://rubygems.org/
- Ruby Standard Library - http://www.ruby-doc.org/stdlib-1.9.3/
-
Pry (http://pry.github.com) is a high-powered replacement for irb. It is working its way toward being a REPL (Read-Eval-Print-Loop) for Ruby, but it is also seeing use as a debugger. For example, it's possible to use Pry as a replacement for the Ruby on Rails Console. So, I'd like to have a way to use Pry as a debugger and/or console in SketchUp.
Unfortunately, I'm not sure exactly what this would require. Pry is known to work with Ruby 1.8.7, but might not work (unchanged) under 1.8.6. There is also the question of enabling some sort of inter-process communication between SketchUp and Pry. Nonetheless, I'm sure that it's possible and also confident that it would be a handy tool for SketchUp developers.
-
@richmorin said:
SketchUp 8 uses Ruby 1.8.6 as its embedded Ruby interpreter.
AFAIK ... even the Mac version of SketchUp 8.0 still ships using MRI 1.8.5 initial release.
Two problems:
1) The 1.8.5 branch is obsolete, and no longer being patched. Out Nipponese friends in the Ruby Core group call it "deceased."
2) It was great that they shipped Win32 SketchUp 8.0 with MRI 1.8.6-p287, instead of the original release of 1.8.0 ! (pssst! That's a big ZERO on the end there!)
-
But that was not something we ourselves could not do. (On PC we just put a newer DLL file in the Sketchup binary directory, and Sketchup loads it, if it has the same name.)
-
What we asked for was to bring the two platform editions up to the same MRI release.
What we got was ignoring the Mac MRI version, and bringing the PC edition up the the last available MS Visual Studio pre-compiled binary patchlevel in 1.8.6 (p287,) even though there were newer patchlevels in 1.8.6, and 1.8.7 was available with the same or higher patchlevels.
So.. it seems Google was unwilling to fund a day's work to compile newer versions for Sketchup on both platforms.
We all had "rose tinted" glasses on when it came to Google. We felt that they were so big, and capable of producing very good products, they just HAD to want to make SketchUp what we needed it to be, and what we wanted it to be.
Well... now, we can look back and see what their motivations were, and that those motivations were the limit of their desires when it came to SketchUp.
We all, and most especially the team members in Boulder, have to be happy for Trimble's acquisition of SketchUp. Otherwise... we'd be reading a "Dear John" letter from Google concerning SketchUp. (I'm sure many here, have read those announcements before, with other applications, whose names have now faded into history.)
-
-
@dan rathbun said:
So.. it seems Google was unwilling to fund a day's work to compile newer versions for Sketchup on both platforms.
They where looking at newer versions - but there where compatibility problems.
-
The thread linked below looks relevant to any attempt to augment the Ruby Console (with or without Pry):
-
@thomthom said:
@dan rathbun said:
So.. it seems Google was unwilling to fund a day's work to compile newer versions for Sketchup on both platforms.
They where looking at newer versions - but there where compatibility problems.
Really ?? I do not believe that statement is entirely true.
I am currently running PC Sketchup with Ruby v1.8.7-p299 compiled for platform i386-mswin32 (which means it was compiled with MS Visual Studio.)
Some of the Mac "power users" have been successful, in changing the symbolic link in the Sketchup bin directory heirarchy, to cause Sketchup to load their "System Ruby", which in most cases is at least up in the 1.8.7 branch.
The only logical conclusion, is that Google GE Div. management, was not willingly to spend time (& money,) bringing both platforms up to the same version/patchlevel, and solve any minor issues.
(Which likely would require the "Team" to tweak and compile two Ruby editions themselves. I think they did this at one time, long ago, since the Mac edition has a framework-ized implementation.)I remember quite well, that YOU, Thomas, actually asked them when they updated the PC edition to Ruby 1.8.6-p287, why they did not go with a newer patchlevel (in 1.8.6,) or even the latest patchlevel in 1.8.7.
The answer was a terse, political correct, reply, along the lines of "WE needed to upgrade for our internal needs." This was at the time that they were integrating the newer Street View and Google Earth set location features.
I found the answer a bit odd, since we developer's had been screaming for a newer Ruby version, at least all through the SU7.x development cycle. Anyway.. the answer was just "dripping" with an implied "internal politics - please don't ask more."Anyway... v1.8.6-p287, was SO MUCH better than the old "dead" initial Ruby release of v1.8.0 that we PC guys, could not really complain much.
The big disappointment, was that they have left the Mac edition, wallowing in Ruby v1.8.5-p0 (which is obsoleted by many newer patchlevels, retired, and no longer being supported.)
We, including Google the company, are all "big boys" and should be able to take some constructive critique. It is not necessary to defend Google.
I am sure there are people on the Boulder team that would love to bring Ruby things up to date.
Let us hope Trimble agrees !
-
Don't know about 1.8.7 - but they tried 1.9 I think.
-
@thomthom said:
Don't know about 1.8.7 - but they tried 1.9 I think.
So did I !!The main issue is that that they (the Ruby Core guys,) renamed functions on the c-side, without leaving aliases that would properly call the newer named functions. This is the character encoding realm.
Advertisement