Offline
@garry k said:
Additionally I am experiencing a link error when trying to build SUEX_HelloWorld and SUEX_UsingSWIG
I'm guessing that the compiler can't find the SDK.
You don't need SWIG to make a Ruby C/C++ Extensions. If you just want to use the C API licensing features you just need the basics of what SUEX_HelloWorld demonstrate and then add the C API headers and libs to the project.
I wrote an extension a few years ago that will draw the bounding box as edges: https://bitbucket.org/thomthom/draw-boundingbox/src/f08e7f6efba7712b56a535e4dae4ade3f9bde7af/src/tt_draw_bb/core.rb?at=master
You can rip that code if you want.
@tig said:
I had a sneaking suspicion that his Douglas-Peucker was for curve-simplification...
That's correct - I used it with the intent to simplify contour data from imported CAD drawings.
How are you installing the extension?
Are you using a User or Administrator account?
@archidave said:
but in SU 2015;
> 2.m.abs
gives the NoMethodErrorThis is pretty bad (it has broken my plugin for SU 2015) and means I now need to go hunting through the code for all occurrences of <Length>.abs replacing them with <Length>.to_f.abs and building-in extra validation where the class is not intrinsically known, just in case there could be a Length instead of a Float.
The Length class used to be a subclass of Float. However this isn't really possible in Ruby, but from the Ruby C API this was hacked together a way to do so.
When we added 64bit support in SU2015 this broke because the data structures where different. So we had to re-implement Length by forwarding the methods to Float. Initially this used the Ruby Standard Library, but due to another bug in Ruby where the StdLib would not always load if there was unicode characters in the user's username the StdLib would fail and the Length class would not properly initialize. There was also a bug in SU at some point where the StdLib would fail to load if the user started SketchUp by double clicking an SKP file.
We later corrected the new Length implementation to not use StdLib so it would not fail if the StdLib failed to load. And we also fixed the bug regarding starting SU via SKP files.
But those fixes should be in SU2015M2 - so I don't understand why you'd experience such problems. I am not able to reproduce your error.
Can you try without any extensions enabled - just so we can eliminate that possibility?
So - I did this for Vertex Tools. Any implementation is Ruby was slow. I then wrote a tiny Ruby C extension and the performance was 100+ times faster than the fastest Ruby implementation I had.
There is simply so much overhead by Ruby itself that this kind of stuff is better passed off to C - Even with the overhead of converting the point set to C structures and back to Ruby at the end it just blows away pure Ruby computation.
And as it's been mentioned, you want to avoid square root. Since you want to filter point by a given distance, convert the distance to the power of it self and do the distance calculation without square root. Gives your calculation an extra boost.
Note that if only close the currently open instance. If you are deeply nested you need to loop until you are back in the root - (if that's what you desire). And before SU2014 the method was bugged and could mess up geometry if the close was undone. (The method actually creates an undo item)
@joclo said:
I changed the condition from if @face_array[0] && @face_array[0].material == nil and got a Error: #<SystemStackError: stack level too deep>.. Ouch. I believe this is because of excessive recursion, the model comes back with smoothed surfaces half finished so I don't think there's an infinite loop in there. I presume this means I need to rewrite the code algorithmically?
Recursive methods to traverse geometry is likely to cause stack overflow as you'll be recursing thousands of times. Geometry walkers need to "unroll" their loop to avoid this.
Hmm... the error actually complains about a file not found...
Could not find included file 'sketchupConnector'
And an undefined method...
Hard to tell without knowing anything about the extension. But I'd trace down the missing method and file.
Have you tried the Ruby Debugger - letting you step through Ruby code?
https://github.com/SketchUp/sketchup-ruby-debugger
I'm not familiar with SWIG I'm afraid. Bugra set up the SWIG example - I can ping him if it needs be.
SketchUp changed from Ruby 1.8 to Ruby 2.0 in version 2014. So you need to make sure all binaries are compatible with the updated Ruby interpreter.
View.invalidate marks the view for redraw but it might not be updated immediately. It'll be throttled.
View.redraw force a redraw immediately.
View.invalidate should be the first choice - View.redraw should be used when you know you really need it.
I've had to use view.redraw in cases where I make mesh updates in the mouse events (for live mesh preview). There I had to force a redraw otherwise things would appear choppy. But even then I'd try to manually throttle view.redraw.
@msp_greg said:
e, do you (or Thom, or anyone on a mac) have any idea why this happens? FWIW, the main feature of my plugin is exporting and importing files with other software. Those software packages only run on a pc. Hence, I've never felt a need to make my plugin run on a mac...
I think I've seen this when you hook into the load event. Though hooking into the DOMContentLoaded appear to not suffer from this. Hooking into this might differ from browser to browser (glares at IE). (This is where frameworks like jQuery comes to it's good nature.)
@driven said:
I agree about jQuery as it's hard to debug in SU...
I've been meaning to write an article on this topic. With the web console under OSX (thanks to you) and using Visual Studio's JS debugger under Windows debugging is actually quite nice.
@jim said:
Hmm, if you add an empty Group instead of a CPoint it also works; and then you may need to worry less about cleaning up since the empty group will get swept away.
Good point. (No pun intended)
I'll file up the issue internally so we'll look into it.
One thing to beware of is that Sketchup::require/load annoyingly doesn't raise ruby errors - but instead just output the error text. So you might want to hook into $stdout and $strerr to catch that as well. (This is something I suggest only because you mention it was for a personal tool.)
Have you tried to "touch" the old definition first by making a small change like entities.add_cpoint(ORIGIN) then trying to load the new?
unpack("m*").pack("m") gobbles up some characters. Here's an old snippet I used in the past to sniff out the version number: (Works for Ruby 1.8 and 2.0)
<span class="syntaxdefault"><br />module Example<br /><br /> def self</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">read_skp_version</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">file</span><span class="syntaxkeyword">)<br /> </span><span class="syntaxcomment"># Get the size of the file ID block;<br /> </span><span class="syntaxdefault">id_size </span><span class="syntaxkeyword">= </span><span class="syntaxdefault">IO</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">read</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">file</span><span class="syntaxkeyword">, </span><span class="syntaxdefault">1</span><span class="syntaxkeyword">, </span><span class="syntaxdefault">3</span><span class="syntaxkeyword">).</span><span class="syntaxdefault">unpack</span><span class="syntaxkeyword">(</span><span class="syntaxstring">'C'</span><span class="syntaxkeyword">)[</span><span class="syntaxdefault">0</span><span class="syntaxkeyword">] * </span><span class="syntaxdefault">2<br /> </span><span class="syntaxcomment"># => 28<br /><br /> # Get the size of the file version block;<br /> </span><span class="syntaxdefault">version_size </span><span class="syntaxkeyword">= </span><span class="syntaxdefault">IO</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">read</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">file</span><span class="syntaxkeyword">, </span><span class="syntaxdefault">1</span><span class="syntaxkeyword">, </span><span class="syntaxdefault">4 </span><span class="syntaxkeyword">+ </span><span class="syntaxdefault">id_size </span><span class="syntaxkeyword">+ </span><span class="syntaxdefault">3</span><span class="syntaxkeyword">).</span><span class="syntaxdefault">unpack</span><span class="syntaxkeyword">(</span><span class="syntaxstring">'C'</span><span class="syntaxkeyword">)[</span><span class="syntaxdefault">0</span><span class="syntaxkeyword">] * </span><span class="syntaxdefault">2<br /> </span><span class="syntaxcomment"># => 20<br /><br /> # Get the version block data. This will be UTF-16LE encoded. Since Ruby 1.8<br /> # doesn't have the encoding methods we hack it by zapping out all the zero bytes<br /> # in the data string which will give us a regular ASCII string. This works<br /> # because we know the version string is within the ASCII range.<br /> </span><span class="syntaxdefault">version </span><span class="syntaxkeyword">= </span><span class="syntaxdefault">IO</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">read</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">file</span><span class="syntaxkeyword">, </span><span class="syntaxdefault">version_size</span><span class="syntaxkeyword">, </span><span class="syntaxdefault">4 </span><span class="syntaxkeyword">+ </span><span class="syntaxdefault">id_size </span><span class="syntaxkeyword">+ </span><span class="syntaxdefault">4</span><span class="syntaxkeyword">).</span><span class="syntaxdefault">gsub</span><span class="syntaxkeyword">(</span><span class="syntaxstring">"\x00"</span><span class="syntaxkeyword">,</span><span class="syntaxstring">""</span><span class="syntaxkeyword">)<br /> </span><span class="syntaxcomment"># => {15.1.106}<br /><br /> # Extract the version components.<br /> </span><span class="syntaxdefault">version</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">match</span><span class="syntaxkeyword">(/\{(\</span><span class="syntaxdefault">d</span><span class="syntaxkeyword">+)\.(\</span><span class="syntaxdefault">d</span><span class="syntaxkeyword">+)\.(\</span><span class="syntaxdefault">d</span><span class="syntaxkeyword">+)\}/).</span><span class="syntaxdefault">captures</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">map </span><span class="syntaxkeyword">{ |</span><span class="syntaxdefault">x</span><span class="syntaxkeyword">| </span><span class="syntaxdefault">x</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">to_i </span><span class="syntaxkeyword">}<br /> </span><span class="syntaxcomment"># => [15, 1, 106]<br /> </span><span class="syntaxdefault">end<br /><br />end </span><span class="syntaxcomment"># module<br /><br /># Example usage;<br /></span><span class="syntaxdefault">major</span><span class="syntaxkeyword">, </span><span class="syntaxdefault">minor</span><span class="syntaxkeyword">, </span><span class="syntaxdefault">revision </span><span class="syntaxkeyword">= </span><span class="syntaxdefault">Example</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">read_skp_version</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">Sketchup</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">active_model</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">path</span><span class="syntaxkeyword">)<br /> </span><span class="syntaxdefault"></span>
@siim11s said:
I then have a component_list ordered as "last modified", right?
The order is in no guarantied order. It doesn't change when definitions are modified.
@siim11s said:
I hope you understand what I'm trying to do
I'm afraid it's a bit unclear to me.
Are you trying to rename all definitions?
What is the expected result?
@siim11s said:
Now when I need to make a new component and place it as number "052" for example - I'd need to rename all the components that follow.
Why do you need to rename all the other components to place a new component?
@tommyk said:
I did NOT think of that! For my purposes, this may do the trick. Thanks!
Beware that users might not like that extensions arbitrary change the settings of the style they have set up.