You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These should either throw an error or (even better) we would have some sort of language pragma or just a knob that would allow these (and they would also need escad parser counterparts).
With a knob, we could have a properly extended openscad engine, while also having an ability to disable it for OpenSCAD compatible mode.
@sorki Nice catch! I've done a quick fix using error like the other unsupported primitives, but it feels clunky. I think a type class based approach where the valid escad objects are separated from extended objects, and instances for exporting to escad ensure that nothing unsupported is sneaking in.
This would probably be a fairly decent change, so I think we can fix this specific problem now and fix the general case later.
Sounds good! You could also try to switch the function not to use error but rather return Either and for now throw an error in calling export one since the export functionality doesn't consider the case of exports failing.
These should either throw an error or (even better) we would have some sort of language pragma or just a knob that would allow these (and they would also need escad parser counterparts).
With a knob, we could have a properly extended openscad engine, while also having an ability to disable it for OpenSCAD compatible mode.
cc @lepsa
The text was updated successfully, but these errors were encountered: