New Material Methods! (With bugs :( )

thomthom

It is working as intended. It would all make sense if you guys could see how the Ruby API is implemented in SU.
The Ruby API is a very thin wrapper around our C++ code.

In this case I think it might have been too thin. I can't think of a case where you want to remove a material just from the manager and not the model entities. As it is now it needs to be clearly documented that it orphans the material and the developer that uses it needs to takes care of removing it from the model. Because once it's been orphaned one can't locate it in the material collection.

@jhauswirth said:

What everyone is asking for is probably a new method in model called model.remove_material (you guys can start
another thread on what it should be called). This new method would live in model because
model owns Materials and the entities that are assigned the materials. So model has all the info
needed to implement what you are asking for.

But wouldn't that be inconsistent Pages.erase ? Pages internally contain a reference to it's owner Model via .parent. Couldn't materials.remove also do this? Just seems more neater organized that way. And it's where I'd be starting to look if I was looking for such a method.

@jhauswirth said:

Sorry for messing this up, I sneaked these new methods
in right before release which didn't get properly reviewed by the beta group because there were no
release notes made for the new methods.

These method has been high on the request list, so it's good to see it. But yes, would have been good if they had gone through at least one round of testing.
The Material.name= appear to work as expected though. It's just this Materials.remove which has potential for causing issues. But at least it allows us to remove materials from the list without purging and creating temp geometry etc. I already made a wrapper for the function that remove the material from the entities before removing it from the material manager, but I wonder if it would have been faster if done natively from SU instead of via the Ruby API?

thomthom

@dan rathbun said:

@thomthom said:

But there is no knowing of which other plugins has done this.

Dont say there is no way, just because you don't know how (..YET,) ... remember Ruby is cool! Ruby will find a way, or allow a way through it's immaculate dynamistic glory.

.method_added http://stackoverflow.com/questions/175655/how-to-find-where-a-ruby-method-is-defined-at-runtime

I'm thinking I could make a debugging monitoring class that loads first and monitors the base Ruby and SketchUp classes and modules for extensions.

Jim

tattletale.

I'm not sure you need to "monitor", but an as-needed check of the files in plugins would be sufficient.

thomthom

@jim said:

I'm not sure you need to "monitor", but an as-needed check of the files in plugins would be sufficient.

Yes, a debug tool, that's what I intended. "Monitor" because one couldn't just get the load path for any method. Need to hook into at the beginning before anything else.

Dan Rathbun

@unknownuser said:

I'm thinking I could make a debugging monitoring class that loads first and monitors the base Ruby and SketchUp classes and modules for extensions.

I also.. have a couple of methods proto'd out. I was thinking they need to be in a common namespace. How about: SKX::Dev ??

@jim said:

tattletale.

Yep.. I didn't want to "publish" the method publically, as there can be only one "monitor", or they'd be fighting each other to override it.

@unknownuser said:

"Monitor" because one couldn't just get the load path for any method. Need to hook into at the beginning before anything else.

@jim said:

I'm not sure you need to "monitor", but an as-needed check of the files in plugins would be sufficient.

Much more efficient to 'hook in at the beginning' that way you can detect when a rbs file does an override. Ruby can tell you the file and line number without having to parse actual files. (Even Kernel.set_trace_function can do it.)
One issue however is that "the method" will report ALL methods created once monitoring begins, so definately some filtering will be needed to ignore methods added to custom classes and modules. Otherwise you'll flood $stdout or the logging object (file, hash etc.)