Who changed extensions.rb?
-
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.
-
@adamb said:
Can we use Ruby namespaces to sandbox each plugins view of the SketchUp classes?
Sometimes this works.. many times not.
The major problems are with the Sketchup::Drawingelement subclasses. All the API add entity methods (as well as the Dynamic Components extension,) are hardcoded to only accept exact class names (such as Sketchup::Face,) instead of accepting arg.kind_of?(Sketchup::Face)
So cloning the toplevel Sketchup module into another namespace may not work.
EDIT: But don't let my thots keep you from experimenting ... (I'd be happy to be proved wrong on this.)
-
@chris fullmer said:
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
Chris,
I did it actually. See this post, which contains the modified version
May be we should publish it in a place which is more accessible
Fredo
Advertisement