Who changed extensions.rb?
-
We were investigating a problem where our GeoSketchFree plugin failed to load, and found the reason to be that a modified copy of extensions.rb was in the user's Plugins directory, apparently installed as part of another plugin.
When Sketchup is installed, extensions.rb in placed in the Tools folder rather than the Plugins folder (presumably to protect it from being changed). By placing a modified copy in the Plugins directory, the Sketchup version is bypassed, and extensions do not work as designed by Google. In this case, the difference was that the modified version used the Ruby require command rather than Sketchup::require to load the extension.
Is there any concensus among plugin developers concerning making such a change to extensions.rb?
Our opinion is that this is not a good practice. By overriding the Sketchup version of extensions.rb, extensions do not work as designed and documented by Google. This can have an adverse effect on other plugin developers.
Rather than changing the standard Sketchup definition of load for a SketchupExtension, it would be better to add a new unique method (e.g. "MyApp_load") to the SketchupExtension class, and use that to load an extension that cannot use the Sketchup::require for some reason.
-
You are of course correct that standard files and methods should not be changed.
It's easy enough to write your own code and files and leave these alone...
There were one or two leper scripts that overwrote methods etc and made life awkward, but these were very rare, and most are no longer in development...I have almost every Plugin known to man and there is no extensions.rb in my Plugins folder... only the standard one found in Tools, that's not been changed for several years...
Have you any idea where the rogue copy came from ?
If so publish the culprit and we can get it sorted...
I know of no tools that would add that duplicated file...Did this user perhaps once have a really old version of Sketchup from which he has copied over his files at some time, perhaps including extensions.rb when it was once kept in Plugins?
Some users are particularly 'challenged' when installing even the simplest of scripts and it wouldn't be beyond some of them to copy or move scripts between Tools and Plugins particularly when they've never been told to do so
Although the difference in the files coding is perplexing is the (c) the same the the correct version or earlier ?? -
Yes, it appears to be an old version of extensions.rb, the copyright is 2005, and still refers to "@Last Software".
As part of diagnosing the problem, I asked him to rename the extensions.rb in the Plugins directory. When he did this, our plugin loaded correctly, but he said that a plugin called "Instant Roof" crashed with a BugSplat. I have not installed "Instant Roof", so I don't know if it installs the modified extensions.rb
As a workaround, I provided a new copy of our plugin loader which is not scrambled. This should make it work with the modified extensions.rb
-
I do have Chuck's InstantRoof and it works fine with the newer version of ../Tools/extensions.rb. AND it didn't install any rogue versions of it either...
I suspect that your user simply had an old copy of the @Last's extensions file that somehow got into Plugins, it should be discarded, as loading it at all will probably cause issues... Your user has an old file in a folder where it shouldn't be - just get him to rename it with a trailing .txt suffix so that it doesn't auto-load at all, and everything should then be fine - the script that supposedly wants the old version might fail... BUT InstantRoof is NOT that script...
In passing it is somewhat pointless scrambling your short piece of 'loader' ruby as it has no intellectual property value anyway ??
It only becomes at issue when the extension code is called from within scrambled code, which is wholly avoidable... perhaps InstantRoof has that issue when the old version loads first and the new version does too as they have different names after your renaming 'trick'.
-
Well, darn, I had the extensions.rb plugin also in my plugin folder. And yes it was an old version of extensions.rb, the copyright is 2005, and still refers to "@Last Software". I have another copy in the tools folder, Copyright 2005-2008, Google, Inc.
Maybe that is the root of some of my problems I have had every so often.
Thanks for the heads up.
Ken
-
i suspect your user has come across a .zip for download that i've seen on the interweave and they actually installed it..
the zip contains a 90MB plugins & a 35MB tools folder and they're filled with various plugins.. file mgmt is very poor-- for instance, there's freescale & fredoscale and on top of that, there are all the various updated files that need to be replace upon updating certain scripts.
some of the files in the plugins folder are also in the tools folder etc..
the tools folder contains the extensions.rb that's dated 2005-2008 while the plugins folder contains the extensions.rb file dated simply 2005.
i'd love to post the link here so you all could have a laugh at this mess but unfortunately, the folders also contain a few premium plugins.
[but yeah, i'm just listing one possibility and am in no way accusing your user of pirating.. (well, maybe in a small way i am doing just that but i'm just someone on the internet so my opinion doesn't matter
)][edit] see.. ken had the double extensions file so maybe your guy didn't come across this zip i'm talking about afterall
-
As a 'health-check' can I suggest that anyone who thinks they have a mess up looks in their ../Plugins folder for the following .rb files that ought to appear only in their ../Tools folder.
If they are in the wrong folder move them [back] into ../Tools; if they are duplicated then remove the Plugins folder's version.
Depending on your SUp version, and what optional tools you might have, you could have these .rb files...
Which should be in ../Tools if you have them at all...
The bold ones are the base-set for most setups and have been around for several versions...advancedcameratools
date
dynamiccomponents
extensions
filmandstage
langhandler
make_pano_pm
rational
sandboxtools
shadowstringsfix
sketchup
SolarNorth
webtextures
Several of these have matching subfolders - e.g. 'Sandbox' within ../Tools too...
If you are in any doubt ask.
Don't delete any duplicated files you find but rather move them into a [new name='disabled'] subfolder so they don't auto-load - then you can always restore them when you've gone wrong -
TIG,
Yes , I had actually intended for GeoSketchFreeLoader not to be scrambled. That is the reason it is so small. When the installer was made, it inadvertantly got scrambled. But it should have worked anyway, and does with the Google version of extensions.rb.
Regarding InstantRoof, I was only reporting the symptom reported to me. I don't know why InstantRoof would crash when the modified extensions.rb was removed, unless something else was changed accidently.
Jeff
-
THe plugin SCF Power toolbar by CadFather is the one that may distribute extensions as well as sketchup.rb. Possibly his other toolbars do as as well.
Nice idea - bad implementation.
-
@jim said:
THe plugin SCF Power toolbar by CadFather is the one that may distribute extensions as well as sketchup.rb. Possibly his other toolbars do as as well.
Nice idea - bad implementation.
Has someone told him to stop ???
-
@tig said:
Has someone told him to stop ???
I mentioned it here:
http://forums.sketchucation.com/viewtopic.php?f=323&t=27592&start=0
-
There is a plugin out there that changes some base classes that has been known to crash many plugins:
sunposition.rb
If they have that in their plugins folder, instant roof will break, so will thea exporter, surface gen, and many others. If they have that script, they should burn it like the plague and never use it again.
It does not, however, mess with the extensions.rb file. I tend to think that they copied that from previous plugins folders, back when that file used to be put by default in the plugins folder in version 5 (or maybe it was 4). Anyhow, just have them delete it, they won't need it. And delete sunposition.rb as well, if they have that.
Chris
-
Its incredibly annoying when people put out these crappy plugins like this.
I still have to check for that ****ing "Matchbox" plugin which totally screws the Sketchup 'class' system.
But you know, the headlong rush to these highly introspective/reflective languages which offer little in the way of "sealing" code is such a problem.
A Class definition once defined should be sealed and immutable. If you wish to specialize then derive from the super class and specialize-away, but being able to post something and walk away is pretty dangerous.
Can we hunt him down and have him shot? Thats reasonable isn't it?
Adam
-
I don't know if it is Sunposition tha removes or add the extension.rb, but, as said by Adam, it is for sure the source of conflicts because it overrides basic Ruby classes (and strangely for no special reason).
I came across this conflict between Sunposition and Curviloft.
I tried to contact the author, but still no answerSee that post, where I posted a modified version of sunposition.rb which is clean vis-avis Ruby and Sketchup
Fredo
-
I did something similar with someones 'VirtualWind' script that messed with progressbar...
-
I also contacted the developer of Sunposition - twice - still no response...
-
Hey, here's a thought.
Given we can't enforce a 'developer quality threshold', there is always going to dodgy code out there.
Can we use Ruby namespaces to sandbox each plugins view of the SketchUp classes? So if a plugin chooses to redefine true to be false and false to be SketchUp::Face etc. Well, it will just die in their plugin. Not mine.
So something like alias the Sketchup:: namespace to be unique for each plugin.
How hard can it be? I'll leave the easy bit to others..
have a good one.
-
you developers here on SCF could institute a rating system that told we layman if a plugin met certain standards. and that would give incentive to developers to meet that minimum standard if they wanted the SCF audience.
-
Could we just re-write the sunposition plugin and send him an updated copy? It does not re-write that much. I started doing it yesterday, but in the end got in a little bit over my head. Anyone wanna give it a go?
Chris
-
@adamb said:
A Class definition once defined should be sealed and immutable. If you wish to specialize then derive from the super class and specialize-away, ...
The augmentation of Ruby objects at runtime is a very powerful (and one of my favorite,) features of the Ruby language. This is what is called a Dynamic Language.
Without it, Ruby would be as mundane as Pascal, etc.
Advertisement