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
It's been a few months that I have been contributing to pylele: the aim of this project is to have a python-based framework to design ukuleles for 3d printing (but potentially any type of stringed instrument).
Over time we have experimented with different 'apis', or backend that generates geometries: we support 5 at the moment.
So we have a single 'api' that supports generating 3d objects with any of those backends from a single script.
This means at the very least we have built some kind of 3d geometry library benchmark, but that is not the point.
Now, when I try to add new features, I find very often someone has already written a useful piece of library in openscad.
While I can import and use any .scad file with solidpython2 library, this makes a particular feature available only for the solidpython backend, which is less than ideal.
So the idea I am trying to explore is to build a 'scad2py' function to convert a scad file to a python script based on the pylele api (I know I will need to implement some stuff there, but that is not the part that scares me at the moment).
This would allow to:
reuse a lot of the community based .scad code in other contexts
make the base for a new pure python based openscad interpreter
provide a path to upgrade existing .scad code to a more flexible high level language python
through the use of different backends convert .scad code to other formats of interest (ie scad2step using cadquery)
In principle this is the same you have done here.
It seems to me the scad -> ast (scad2ast) can probably be reused "as is", but the ast -> py (ast2py) obviously needs thorough reworking.
One thing that I do not like of the current ast2py is the readability of the python file. While I understand the use of decorators allows an output code that looks closer to the original scad syntax, I think it would be preferable to have a more "pythonic" and compact output.
I attach the current python output for comparison with the current implementation. tube_scad.txt tube_py.txt
So I'd like to know if you had considered a 'pythonic' output code and discarded it for some difficulty in implementation.
And, could give me some guidance in building a new transformer in that direction?
Because I am a bit lost simply looking at the compiler.py code...
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi, thank you for sharing this work!
It's been a few months that I have been contributing to pylele: the aim of this project is to have a python-based framework to design ukuleles for 3d printing (but potentially any type of stringed instrument).
Over time we have experimented with different 'apis', or backend that generates geometries: we support 5 at the moment.
So we have a single 'api' that supports generating 3d objects with any of those backends from a single script.
This means at the very least we have built some kind of 3d geometry library benchmark, but that is not the point.
Now, when I try to add new features, I find very often someone has already written a useful piece of library in openscad.
While I can import and use any .scad file with solidpython2 library, this makes a particular feature available only for the solidpython backend, which is less than ideal.
So the idea I am trying to explore is to build a 'scad2py' function to convert a scad file to a python script based on the pylele api (I know I will need to implement some stuff there, but that is not the part that scares me at the moment).
This would allow to:
In principle this is the same you have done here.
It seems to me the scad -> ast (scad2ast) can probably be reused "as is", but the ast -> py (ast2py) obviously needs thorough reworking.
One thing that I do not like of the current ast2py is the readability of the python file. While I understand the use of decorators allows an output code that looks closer to the original scad syntax, I think it would be preferable to have a more "pythonic" and compact output.
For instance, given this input file
I would like an output like this
Or perhaps even better:
I attach the current python output for comparison with the current implementation.
tube_scad.txt
tube_py.txt
So I'd like to know if you had considered a 'pythonic' output code and discarded it for some difficulty in implementation.
And, could give me some guidance in building a new transformer in that direction?
Because I am a bit lost simply looking at the compiler.py code...
Beta Was this translation helpful? Give feedback.
All reactions