Changes in 2015

Dan Rathbun

And point.to_a STILL returns [ Float, Float, Float ] on all my installs.

So it follows that:
x = point.to_a.x

1.0
x.class
Float

kwalkerman

yes, all those workarounds work... But wouldn't it have made more sense to leave point.x as a float as it has always been? In 2015 to convert any number to a length, you just have to do num.to_l so if you wanted point.x as a length all you would need to do is: point.x.to_l ... and all of us who wrote code years ago don't have to go back and tease out the old code...

This one hasn't tripped me up as much as I thought it would so far... just needed to add .to_f in a few places.

Dan Rathbun

@kwalkerman said:

But wouldn't it have made more sense to leave point.x as a float as it has always been?

But I disagree! It does NOT return Float on ANY of the previous versions back to v8 that I have installed.

It always returns a Length instance.

Make sure you do not have some plugin like "Sketchy Physics" that changes API classes installed.

kaas

I just noticed in one of my plugins that loading a single small skp file (to use as a component definition) seems to take almost 1 second whereas the same code in SU 2014 loads the skp instantly.

t = Time.now f = "c:/box.skp" d = Sketchup.active_model.definitions.load f puts (Time.now - t)

edit: added some test code.

Create a simple box in R2014 and save as a skp file (in the code above, in the root of C).
ReStart Sketchup2014 (to prevent 'recursive errors')
run the above code in a ruby editor - 0.3 seconds
Start Sketchup 2015, run the above code - 0.84 seconds

It's half a second difference but it gets annoying fast if a user has to pick & load multiple components (and don't want to pre-load all of them). It breaks the snappy flow of the plugin.

Question: any way to avoid this. Looked in the changelog / bugfixes for 2015 but can't find anything related.

tt_su

@kwalkerman said:

In previous versions of SU, x,y and z coordinates of a Point3d were always returned as a float with the units being inches.
Similarly, the length of an edge was always returned as a float with the units being inches.

That doesn't sound right. The Point3d class was never changed. And when I test this in SU2014 I'm seeing same results in SU2015 as in previous versions.

SU2015
` Sketchup.version
15.0.9350

ORIGIN.z.class
Length

Sketchup.active_model.entities.add_line([0,0,0],[9,9,9]).length.class
Length`

SU2014
` Sketchup.version
14.1.1282

ORIGIN.z.class
Length

Sketchup.active_model.entities.add_line([0,0,0],[9,9,9]).length.class
Length`

SU2013
` Sketchup.version
13.0.4812

ORIGIN.z.class
Length

Sketchup.active_model.entities.add_line([0,0,0],[9,9,9]).length.class
Length`

If you see different result, can you try with no extensions loaded?

@kwalkerman said:

"Length" with the units being the current model units.

A length store it's value as a float. It's just that the to_s method is different so it will print using the model units.

tt_su

@kaas said:

I just noticed in one of my plugins that loading a single small skp file (to use as a component definition) seems to take almost 1 second whereas the same code in SU 2014 loads the skp instantly.

Is this with any SKP? Can you share that SKP?

tt_su

@dan rathbun said:

But I disagree! It does NOT return Float on ANY of the previous versions back to v8 that I have installed.

Confirmed - our source code has always been returning Length objects for Point3d members and Edge lengths.

Dan Rathbun

@tt_su said:

@dan rathbun said:

But I disagree! It does NOT return Float on ANY of the previous versions back to v8 that I have installed.

Confirmed - our source code has always been returning Length objects for Point3d members and Edge lengths.

Interestingly,... the API does not actually say what the return class is. IT says "value".

Dan Rathbun

@tt_su said:

@kaas said:

I just noticed in one of my plugins that loading a single small skp file (to use as a component definition) seems to take almost 1 second whereas the same code in SU 2014 loads the skp instantly.

Is this with any SKP? Can you share that SKP?

Bigger thumbnail = more loading time? (guessing)

tt_su

@dan rathbun said:

Interestingly,... the API does not actually say what the return class is. IT says "value".

Yea... one of the many improvements to be made.

kaas

@tt_su said:

Is this with any SKP? Can you share that SKP?
Any skp will take longer to load with that code in SU 2015 compared to SU2014.. at least on my system. Would like to see if anyone else could confirm or even better, have a solution.

Brighter3D

SU2015 can be installed in two versions 32 and 64bit.
Is there a way to check which is installed from ruby api?

Sketchup.version
returns: 15.0.9350

driven

from the API

 if Sketchup.respond_to?(;is_64bit?) && Sketchup.is_64bit?
   # Load 64bit binaries.
 else
   # Load 32bit binaries.
 end

Brighter3D

Thanks!

Brighter3D

Packing float value into two integers, and passing to double parameter function,
seems no longer works in 64bit SU2015.

passF = Win32API.new(mydll,"PassDouble",["L","L"],"V")

packedF = [rubyFloat].pack("D").unpack("LL")
passF.call(packedF[0],packedF[1])

Any tips?

wbarnes05

I noticed the change regarding the Length class a few days ago in the API. What's weird is that the API states that the parent of Length is Object starting in SU 2015. That had me worried as it implies that mathematical operations will no longer work on an instance of Length. However everything continued to work ok in my plugin when running in SU 2015.

I ran a few tests in 2015 and found the following:

length = 4.to_l
4"
length.is_a? Integer
false
length.is_a? Float
true
length.is_a? Length
true
length.class.superclass
Numeric
length.class.ancestors
[Length, Numeric, Comparable, Object, Kernel, BasicObject]

It would appear then that the API is incorrect and should be changed to show that Numeric is the parent class.

kaas

@dan rathbun said:

@kaas said:

I just noticed in one of my plugins that loading a single small skp file (to use as a component definition) seems to take almost 1 second whereas the same code in SU 2014 loads the skp instantly.

Bigger thumbnail = more loading time? (guessing)

I can't imagine. The box.skp testfile I created was just a rectangle with an extrusion.

Still looking for a solution. I tested all kinds of files and the result is always the same: loading a skp file as a component definition takes 2 to 3 times as much in SU2015 compared to SU2014 with the code above.
I tested disabling all plugins. I also tested loading SU2015 skp files (I wanted to rule out it took additional conversion time from SU2014 to SU2015).

Any suggestions / workarounds ?

slbaumgartner

@dan rathbun said:

Bigger thumbnail = more loading time? (guessing)

Seems unlikely to me unless it was programmed really badly. The thumbnail contains nothing that SketchUp needs for loading the file, so the loader should simply skip that part of the file with nearly zero impact on load time. Where a larger thumbnail would have an effect is on save or quit, when SU has to write the thumbnail. I think something else must be afoot, but at this point I have no clue what...

Steve

tt_su

@brighter3d said:

Packing float value into two integers, and passing to double parameter function,
seems no longer works in 64bit SU2015.

passF = Win32API.new(mydll,"PassDouble",["L","L"],"V")

packedF = [rubyFloat].pack("D").unpack("LL")
passF.call(packedF[0],packedF[1])

Any tips?

It's a bit vague - what exactly doesn't work of these calls? Do you see Ruby's packing methods returning different results?
Is the DLL you are calling actually 64bit?
Does the function you are calling actually use ints - or are you using some other type that might be different on 64bit OS?

On a side note - the Win32API has been deprecated for a long time. It has many limitations and is easy to cause crashes with. The recommended now is using Fiddle.

tt_su

@wbarnes05 said:

I noticed the change regarding the Length class a few days ago in the API. What's weird is that the API states that the parent of Length is Object starting in SU 2015. That had me worried as it implies that mathematical operations will no longer work on an instance of Length. However everything continued to work ok in my plugin when running in SU 2015.

I ran a few tests in 2015 and found the following:

length = 4.to_l
> 4"
> length.is_a? Integer
> false
> length.is_a? Float
> true
> length.is_a? Length
> true
> length.class.superclass
> Numeric
> length.class.ancestors
> [Length, Numeric, Comparable, Object, Kernel, BasicObject]

It would appear then that the API is incorrect and should be changed to show that Numeric is the parent class.

The API docs needs updating in general to make the hierarchy more clear. There are many inconsistencies. We have a big todo item to improve the whole developer site. Stay tuned.

@wbarnes05 said:

That had me worried as it implies that mathematical operations will no longer work on an instance of Length. However everything continued to work ok in my plugin when running in SU 2015.
We had to pull some tricky shimming to prevent breaking stuff. I wasn't able to do a 100% compatibility, but I think we have a near 99% use case coverage. Main one is C Extensions doing low level type checks for Floats which used to work, but not any more.