Subtle difference between solidpython object and bos2l object with left(), right(), back(), forward()

[taliesin]

I've got a python function, that

def distributed4x(something, cw, cd):
    "create 4 incarnation of something cw and cd apart"
    return something.left(cw/2).forward(cd/2) + something.right(cw/2).forward(cd/2) + \
        something.left(cw/2).back(cd/2) + something.right(cw/2).back(cd/2) 

which produces the expected results when used with cylinder.

cph = cylinder(h=100, d=8, center=True)
cp = distributed4x(cph, 200, 300).color('green')

but not if 'something' is a bosl object like

import import solid2.extensions.bosl2 as b2

cph = b2.cylinder(h=100, d=8, center=True)
cp = distributed4x(cph, 200, 300).color('green')

It's because it's translated differently, for the cylinder example it becomes

    color(alpha = 1.0, c = "green") {
        union() {
            translate(v = [0, 150.0, 0]) {
                translate(v = [-100.0, 0, 0]) {
                    cylinder(center = true, d = 8, h = 100);
                }
            }
            translate(v = [0, 150.0, 0]) {
                translate(v = [100.0, 0, 0]) {
                    cylinder(center = true, d = 8, h = 100);
                }
            }
            translate(v = [0, -150.0, 0]) {
                translate(v = [-100.0, 0, 0]) {
                    cylinder(center = true, d = 8, h = 100);
                }
            }
            translate(v = [0, -150.0, 0]) {
                translate(v = [100.0, 0, 0]) {
                    cylinder(center = true, d = 8, h = 100);
                }
            }
        }
    }

for the b2.cylinder it is:

     color(alpha = 1.0, c = "green") {
        union() {
            translate(v = [0, 150.0, 0]) {
                left(x = 100.0) {
                    cylinder(center = true, d = 8, h = 100);
                }
            }
            translate(v = [0, 150.0, 0]) {
                right(x = 100.0) {
                    cylinder(center = true, d = 8, h = 100);
                }
            }
            back(y = 150.0) {
                left(x = 100.0) {
                    cylinder(center = true, d = 8, h = 100);
                }
            }
            back(y = 150.0) {
                right(x = 100.0) {
                    cylinder(center = true, d = 8, h = 100);
                }
            }
        }
    }

NOTE: I'm not much of an OpenSCAD programmer, so I might be missing something obvious.

[jeff-dh]

Hmmmm... sh**......

The reason is that bosl2 brings it's own back, forward, left,..... commands and SolidPython (without bosl2) brings its versions (since OpenSCAD itself does not have them). The one (back and forward) defined in SolidPython (which are inherited from SolidPython"v1") are defined the other way around as the bosl2 ones.

I think we need to changed it, but this will cause another major backwards compatible breaking change......

I'll think about it for a couple of days, but I don't see any other way than a backward compatible breaking change.

Thanks a lot for finding this!

[jeff-dh]

Btw: Take a look at the distributors from bosl2, grid_copies do exactly what you want:

https://github.com/BelfrySCAD/BOSL2/wiki/distributors.scad#functionmodule-grid_copies

[taliesin]

BOSL2 seems to be twisting your nerves quite a bit.

Thanks for the grid_copies() hint, thought there might be a BOSL way, but it was just too easy doing it in Python (which is closer to my base :-) )

[jeff-dh]

On Sat, 16 Dec 2023 06:54:23 -0800 taliesin @.***> wrote:

BOSL2 seems to be twisting your nerves quite a bit.

Well, actually it's not bosl2, but making the heritage of SolidPython(v1) consistent with bosl2 (which is probably "more correct" in detail - how back/forward are defined and the cylinder parameters up until now).

But I think it's worth it, a good (and consistent) bosl2 integration into SolidPython is the path I think is the right way to go in the long term. Unfortunately it causes backwards compatibility issues in the short term.

[jeff-dh]

In other words: bosl2 is pointing out some "fundamental" issues (like what's back and what's forward) in SolidPython itself which did not get questioned before....

As mentioned before, I'm convinced it makes sense to fix these issues for the long term but I'm concerned in the short term. And I don't see any alternative that makes sense in the long term....