[Talk] Plugins Quarantine

driven

is it in

> rouge=%Q(Geodesic)
@rouge=rouge
path=%Q(/Library/Application\ Support/Google\ SketchUp\ 8/SketchUp)
@path=path
suspect=(%x(find "#{@path}" \\; | grep "#{@rouge}"))

=> /Library/Application Support/Google SketchUp 8/SketchUp/plugins!/Geodesic_SketchUp.rb
john

TIG

It's probably called something like 'Geodesic_SketchUp.rb' or similar by Gavin Kistner 2004.
It also messes with Group etc unnecessarily...
I have my own 'edited' version that avoids all of this...
I'll PM it to you...

thomthom

@tig said:

It's probably called something like 'Geodesic_SketchUp.rb' or similar by Gavin Kistner 2004.
It also messes with Group etc unnecessarily...
I have my own 'edited' version that avoids all of this...
I'll PM it to you...

Just peaked at the original file. Noticed the modifications to Group and Vector.

Trogluddite

@chrisglasier said:

One could ask why each plugin doesn't get their won environment - but then consider how much overhead that would require to run a separate instance of Ruby for each and everyone of hundreds of plugins. Also - each plugin is accessing the same model entities - how could you place each plugin in a separate environment and still give access to the same model data? You'd get much of the same issues you get with multi-threading

Re-reading this thread after encountering similar issues with another Ruby API entirely (FlowStone DSP programming software), which brought up this very problem of "sandboxing".

Simply, it is a non-starter in Ruby - even if it were desirable (careful what you wish for!), it couldn't be done. Ruby employs a 'Global Interpreter Lock' (GIL). In short, it is only possible to have one Ruby interpreter per process (the SU application being the 'process' in our case).
This is a decision made, and stuck with, by Matz who first created the language. The intention is that this ensures thread safety - and since all plugins must access the same model data, this is pretty important.
It's also why the API cannot access multiple processor cores - the interpreter runs in a single thread. Thus there is, on purpose, very little truly concurrent processing in Ruby - if there were, method calls could be processed "out of order", with the potential to seriously mess up any shared data.

From what I have seen here, it seems that the Ruby 'gurus' have found, and are actively promoting, the most effective and least intrusive solution to the problem. Over at the site for that other software, we are trying to build a similar framework of best practices - and the research we've done indicates that the techniques used here to manage the namespace are pretty much as good as it gets - given the limitations that using 'C' Ruby inherently imposes.

When writing a plugin, then as a developer, I would expect that my geometric calculations etc. were spot on so that the thing actually worked for its intended purpose - and I don't see how expecting the "housekeeping" parts of the plugin to be equally robust is an unreasonable responsibility. Not treading on the toes of the API or other plugins is part of the 'specification' for a good plugin, as important as getting lines and faces in the right place.

Maybe Ruby just makes it too easy? - folks using the more typical C SDKs of other applications have to work a lot harder to make robust add-ons, and things like thread safety etc. have to be considered and accommodated within their designs. Comparatively, wrapping everything in a module, and not messing with the kernel, is really not much to expect - anyone who can understand the API doc's should have no trouble understanding those things too.
The Ruby 'gurus' and mod's do a great job of advising us noob developers, but cannot force amateur dev's to heed their warnings. The techniques involved are not terribly complex (even I understand them!), and I have no problem with developers who consistently refuse to take good advice being censured for the ill effects that their plugins can cause.

thomthom

@trogluddite said:

Maybe Ruby just makes it too easy? - folks using the more typical C SDKs of other applications have to work a lot harder to make robust add-ons, and things like thread safety etc. have to be considered and accommodated within their designs. Comparatively, wrapping everything in a module, and not messing with the kernel, is really not much to expect - anyone who can understand the API doc's should have no trouble understanding those things too.

My impression is that many people, already used to Ruby from web development is used to have full control over their environment. (Even though they run into problems with namespaces if they use multiple frameworks.)

Yesterday I began to write down a checklist of things I've found important to keep in mind when developing SketchUp plugins: http://www.thomthom.net/thoughts/2013/02/sketchup-plugin-checklist/

What I missed when I began developing SketchUp plugins was that there was no firm guidelines. And the documentation even contains some very bad examples. I do hope this will change and I do think it will now with Trimble SketchUp.

It's something that is important when an API is developed - to provide good documentation with guidelines of good practices. Makes the developers using the API happy.

Pixero

@tig said:

It's probably called something like 'Geodesic_SketchUp.rb' or similar by Gavin Kistner 2004.
It also messes with Group etc unnecessarily...
I have my own 'edited' version that avoids all of this...
I'll PM it to you...

Could you please PM it to me as well. I just recently downloaded the geodesic script and didn't know it had problems.

slbaumgartner

@trogluddite said:

Maybe Ruby just makes it too easy? - folks using the more typical C SDKs of other applications have to work a lot harder to make robust add-ons, and things like thread safety etc. have to be considered and accommodated within their designs. Comparatively, wrapping everything in a module, and not messing with the kernel, is really not much to expect - anyone who can understand the API doc's should have no trouble understanding those things too.
The Ruby 'gurus' and mod's do a great job of advising us noob developers, but cannot force amateur dev's to heed their warnings. The techniques involved are not terribly complex (even I understand them!), and I have no problem with developers who consistently refuse to take good advice being censured for the ill effects that their plugins can cause.

To start, many thanks to the moderators for all your work to keep sketchUcation a friendly and useful place!
Personally, I think that the quarantine area is a good idea. Perhaps all plugins should go initially into quarantine until enough members weigh in to confirm that the plugin is safe? That might reduce the workload on the moderators. But certainly there should be VERY LOUD warnings to make it as hard as possible to ignore the fact that known bad plugins are bad. I also agree that if the original author doesn't respond to requests to clean up his code, it should be s#&$-canned - maybe with a residual warning for anyone who downloaded it previously. Our life situations change, and maybe the author no longer has time to devote to SketchUp, but one shouldn't be allowed to post something for free and then just walk away.

Much of the Ruby discussion reminds me of issues that were heatedly debated when weakly-typed, interpreted (i.e. scripting) languages rose to popularity. Those accustomed to strongly-typed, compiled languages opined that it would never be possible to be sure that a program would work, since classes and objects could be arbitrarily modified at any time by code outside the original source files. Despite these objections, in part because of the great power they add via extensibility, scripting languages are now widely used - most of the time, without all the terrible issues that the pundits predicted. But, along comes the occasional troublemaker or naif...

As others have noted, Ruby was deliberately designed so that even the core classes and modules can be modified on the fly by anyone. There are a few situations in which this capability is necessary. The Developer Console and TestUp code on GitHub is an example. They rely on overriding the builtin puts() to trap output from Ruby code (aside: that's all they trap. I added overrides to p, print, printf, and putc in my version because I have scripts that do more formatting than puts). But aside from those kinds of system utilities, I would claim it is never necessary or appropriate to modify the standard libraries. Instead, you derive a subclass, add your override there, and use that instead of the standard class in your code. It's done that way all the time in strongly-typed languages such as C++.

When the SketchUp developers chose Ruby as their extension language, they bought into its mutability along with the rest of Ruby. It seems to me that an outside effort to "undo" this aspect of Ruby would be highly likely to create as many new problems as it solved! Moderators, unless it simply fascinates you, I would put your energy elsewhere!

Steve

thomthom

@slbaumgartner said:

Moderators, unless it simply fascinates you, I would put your energy elsewhere!

"It"?

slbaumgartner

@thomthom said:

@slbaumgartner said:

Moderators, unless it simply fascinates you, I would put your energy elsewhere!

"It"?

"It" = trying to rig SketchUp or sketchUcation so that ill-written plugins are automatically detected and fixed. I won't stand in the way of anyone who enjoys tinkering with that sort of stuff, but I think it won't succeed.

thomthom

Ah, gotcha. Yea, not something I see worth spending time on. Because it won't be able to catch everything anyway.

Instead, a repository where there is a report function where plugins can be flagged - where they then can be investigated.

Possibly, new developers need to have their first plugin validated before it goes live.

Dan Rathbun

It is much less work to track the small number of bad plugins... than to certify all the hundreds (or thousands,) of scripts/plugins.

And a certification program would likely need to be fee based. (It would cost money to maintain the database, pay the "inspectors", and issue the certificates.) Not something the casual coder would want to pay for anyway.

thomthom

Nobody pays us (the moderators) - so why would this not be extended?

ken

Don't mean to double post, however, I may have posted this question in the wrong thread.

Did the Quarantine list become smaller? I remember a lot more plugins in this list. I had a question about a plugin that was quarantined, quarr_jsalign.rb and I was wondering just why this plugin was quarantined.

I use this plugin all the time. To drop component/Group to a set elevation and just wanted to make sure just what it was doing to my Sketchup program.

Now, I see the list is shorter and doesn't include this plugin. Am I looking in the right place or has the list been modified.

Ken

Chris Fullmer

We don't currently put any time into testing every plugin released though. It would in theory add quite a bit of extra time to our moderator duties.