Static Code Analysis for OpenSCAD
The includes / uses in the main file look like this:
include <global.scad>
include <positions.scad>
use <extruder.scad>
use <grabber.scad>
use <NopSCADlib/printed/door_hinge.scad>
include <door.scad>
include <sides.scad>
include <back.scad>
include <base.scad>
include <top.scad>
include <front.scad>
include <shelf.scad>
include <NopSCADlib/printed/box_assembly.scad>
The directory that contains NopSCADlib is found via the path list in
OPENSCADPATH.
OPENSCADPATH=W:/CHRIS/Projects/RepRaptor/OpenSCADLibs
On Sun, 22 Nov 2020 at 21:20, julianstirling julian@julianstirling.co.uk
wrote:
Ah man. I need to do some unit tests on the file importing! Seems to be the
biggest issue so far!
So while that message is pretty unhelpful what it is saying is that it
can't
open the file because it cannot find the file. Are you using a library path
somehow rather than a relative link? I need to get an extensive list of
where OpenSCAD looks and also make a way to pass in the library file.
I'll patch this bug tomorrow.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
There seems to be a problem with for loops with more than one variable. E.g.
for(i = [0 : 1], offset = i * layer_height)
Gives:
box.scad:169:25: W2007: Variable i defined but never used.
box.scad:169:47: E2001: Variable i used but never defined.
On Sun, 22 Nov 2020 at 21:38, nop head nop.head@gmail.com wrote:
The includes / uses in the main file look like this:
include <global.scad>
include <positions.scad>
use <extruder.scad>
use <grabber.scad>
use <NopSCADlib/printed/door_hinge.scad>
include <door.scad>
include <sides.scad>
include <back.scad>
include <base.scad>
include <top.scad>
include <front.scad>
include <shelf.scad>
include <NopSCADlib/printed/box_assembly.scad>
The directory that contains NopSCADlib is found via the path list in
OPENSCADPATH.
OPENSCADPATH=W:/CHRIS/Projects/RepRaptor/OpenSCADLibs
On Sun, 22 Nov 2020 at 21:20, julianstirling julian@julianstirling.co.uk
wrote:
Ah man. I need to do some unit tests on the file importing! Seems to be
the
biggest issue so far!
So while that message is pretty unhelpful what it is saying is that it
can't
open the file because it cannot find the file. Are you using a library
path
somehow rather than a relative link? I need to get an extensive list of
where OpenSCAD looks and also make a way to pass in the library file.
I'll patch this bug tomorrow.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I get lots of things like this
cube([box_width(type) - 2 *
(foot_length - foot_extension), td + 1, 1], center = true);
Gives me
box.scad:236:30: I1001: Overly complicated argument contains 8 tokens.
Not sure it makes sense to simply count tokens. When the argument is a list
the number of tokens is proportional to the list length, should it count as
three arguments? And is the argument to a function call in an argument
valid to be counted?
On Sun, 22 Nov 2020 at 22:22, nop head nop.head@gmail.com wrote:
There seems to be a problem with for loops with more than one variable.
E.g.
for(i = [0 : 1], offset = i * layer_height)
Gives:
box.scad:169:25: W2007: Variable i defined but never used.
box.scad:169:47: E2001: Variable i used but never defined.
On Sun, 22 Nov 2020 at 21:38, nop head nop.head@gmail.com wrote:
The includes / uses in the main file look like this:
include <global.scad>
include <positions.scad>
use <extruder.scad>
use <grabber.scad>
use <NopSCADlib/printed/door_hinge.scad>
include <door.scad>
include <sides.scad>
include <back.scad>
include <base.scad>
include <top.scad>
include <front.scad>
include <shelf.scad>
include <NopSCADlib/printed/box_assembly.scad>
The directory that contains NopSCADlib is found via the path list in
OPENSCADPATH.
OPENSCADPATH=W:/CHRIS/Projects/RepRaptor/OpenSCADLibs
On Sun, 22 Nov 2020 at 21:20, julianstirling julian@julianstirling.co.uk
wrote:
Ah man. I need to do some unit tests on the file importing! Seems to be
the
biggest issue so far!
So while that message is pretty unhelpful what it is saying is that it
can't
open the file because it cannot find the file. Are you using a library
path
somehow rather than a relative link? I need to get an extensive list of
where OpenSCAD looks and also make a way to pass in the library file.
I'll patch this bug tomorrow.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 11/22/2020 11:58 AM, Torsten Paul wrote:
I believe the TOK_ID rule is an accident (that names can start with a
digit), but probably not possible to change anymore.
I was kind of surprised to find that I could name a module "2x4", but it
was nice for modeling lumber.
On Mon, Nov 23, 2020 at 07:56:10AM +0000, Jordan Brown wrote:
On 11/22/2020 11:58 AM, Torsten Paul wrote:
I believe the TOK_ID rule is an accident (that names can start with a
digit), but probably not possible to change anymore.
I was kind of surprised to find that I could name a module "2x4", but it
was nice for modeling lumber.
Aaargh! But then 1a2, 1b3, 1c4 and 1d5 are valid as a variable name,
but 1e6 is not? Sigh!
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
On 23.11.20 09:23, Rogier Wolff wrote:
Aaargh! But then 1a2, 1b3, 1c4 and 1d5 are valid as a variable name,
but 1e6 is not? Sigh!
Correct. But then, there's the option to just not use those.
ciao,
Torsten.
"Correct. But then, there's the option to just not use those. " - I can make
the linter shouty if you use them :D. I plan eventually to have a
configurable regex for nice variable names/module names/function names.
@nophead
I did not push out the promised fix today. Busy busy busy. Still working at
past midnight on something else.
Thanks for the double loop bug. Yeah I treat them the same as I would key
word arguments. I can fix that.
Ah I do not check "OPENSCADPATH". I shall look into this. Will probably be
weird to get it platform independent, but I am on linux you are on windows
so I may have to carry on using you as an alpha tester.
Totally agree about the token counting being dumb. It is in there for my own
purposes as I am cleaning up messy code and so it gives me a sniff of where
to look. But yeah, need to think about complexity in a more intelligent way.
Especially as any decent size list gets flagged! I was thinking of adding
the complexity largest two elements in the list. This way it represents a
list being more complex than a single token, but doesn't scale stupidly.
--
Sent from: http://forum.openscad.org/
It is easy to handle OPENSCADPATH in Python, including the platform
difference:
os.environ['OPENSCADPATH'].split(os.pathsep)
Gives you a list of paths to look in for libraries.
os.pathsep is ';' for Windows and ':' for others.
To remove some of the warnings about argument tokens I factored out some
common sub-expressions into variables. So perhaps there should be a warning
about repeated subexpressions.
On Tue, 24 Nov 2020 at 00:40, julianstirling julian@julianstirling.co.uk
wrote:
"Correct. But then, there's the option to just not use those. " - I can
make
the linter shouty if you use them :D. I plan eventually to have a
configurable regex for nice variable names/module names/function names.
@nophead
I did not push out the promised fix today. Busy busy busy. Still working at
past midnight on something else.
Thanks for the double loop bug. Yeah I treat them the same as I would key
word arguments. I can fix that.
Ah I do not check "OPENSCADPATH". I shall look into this. Will probably be
weird to get it platform independent, but I am on linux you are on windows
so I may have to carry on using you as an alpha tester.
Totally agree about the token counting being dumb. It is in there for my
own
purposes as I am cleaning up messy code and so it gives me a sniff of where
to look. But yeah, need to think about complexity in a more intelligent
way.
Especially as any decent size list gets flagged! I was thinking of adding
the complexity largest two elements in the list. This way it represents a
list being more complex than a single token, but doesn't scale stupidly.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I have a semi-radical idea that I've been thinking of for a while now: Rip the problematic OpenSCAD language out of OpenSCAD and replace it with Python3. Provide backwards compatibility with a translator written in a Python parser.
The syntax would be different, but would not have to be very alien:
difference(
union(
translate([0,0,5]) (Sphere(d=10)),
Cube(10,CENTER).down(1).rotate(z=45)
),
Cylinder(d=5,h=5)
).show()
Or:
Cube(100,CENTER).minkowski(Sphere(d=10)).show();
Modules would become functions or methods, where you just have to explicitly return the geometry.
def tube(id, od, l, children=None):
return union(
difference(
Cylinder(d=od, l=l, CENTER),
Cylinder(d=id, l=l+1, CENTER)
),
children
)
The benefits could be massive:
Variables are mutable.
You can store geometry in a variable.
use/include gets replaced by import, which is less buggy.
Efficient data structures like Dictionaries and Classes are available.
You can assign multiple variables from a tuple returned from a function/module.
You can actually read and parse files from disk.
You can import C and Fortran based geometry libraries like ClipperLib and use them directly. (Via Cython if needed)
You can use Cython for code speed-ups.
There’s a massive pre-existing set of libraries available for all kinds of things.
You would be able to force-render some geometry early to get bounds, vertices, faces, etc.
The Python language has had built-in support for function literals for a long time now.
And much more.
It should be fairly easy to make Python equivalents of all the OpenSCAD language functions and modules, and have them use Cython to call into the same back-end calls that the OpenSCAD language currently calls into. You can keep the current Scintilla editor and rendering GUI.
I would already have written this, except I KEEP swearing to myself that I am NOT going to take on yet another project that I need to support for 20 years.
- Revar
On Nov 24, 2020, at 2:36 AM, nop head nop.head@gmail.com wrote:
It is easy to handle OPENSCADPATH in Python, including the platform difference:
os.environ['OPENSCADPATH'].split(os.pathsep)
Gives you a list of paths to look in for libraries.
os.pathsep is ';' for Windows and ':' for others.
To remove some of the warnings about argument tokens I factored out some common sub-expressions into variables. So perhaps there should be a warning about repeated subexpressions.
On Tue, 24 Nov 2020 at 00:40, julianstirling <julian@julianstirling.co.uk mailto:julian@julianstirling.co.uk> wrote:
"Correct. But then, there's the option to just not use those. " - I can make
the linter shouty if you use them :D. I plan eventually to have a
configurable regex for nice variable names/module names/function names.
@nophead
I did not push out the promised fix today. Busy busy busy. Still working at
past midnight on something else.
Thanks for the double loop bug. Yeah I treat them the same as I would key
word arguments. I can fix that.
Ah I do not check "OPENSCADPATH". I shall look into this. Will probably be
weird to get it platform independent, but I am on linux you are on windows
so I may have to carry on using you as an alpha tester.
Totally agree about the token counting being dumb. It is in there for my own
purposes as I am cleaning up messy code and so it gives me a sniff of where
to look. But yeah, need to think about complexity in a more intelligent way.
Especially as any decent size list gets flagged! I was thinking of adding
the complexity largest two elements in the list. This way it represents a
list being more complex than a single token, but doesn't scale stupidly.
--
Sent from: http://forum.openscad.org/ http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org mailto:Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
That's really not a bad idea!
On 11/24/20 8:59 PM, Revar Desmera wrote:
I have a semi-radical idea that I've been thinking of for a while now:
Rip the problematic OpenSCAD language out of OpenSCAD and replace it
with Python3. Provide backwards compatibility with a translator
written in a Python parser.
The syntax would be different, but would not have to be very alien:
difference(
union(
translate([0,0,5]) (Sphere(d=10)),
Cube(10,CENTER).down(1).rotate(z=45)
),
Cylinder(d=5,h=5)
).show()
Or:
Cube(100,CENTER).minkowski(Sphere(d=10)).show();
Modules would become functions or methods, where you just have to
explicitly return the geometry.
def tube(id, od, l, children=None):
return union(
difference(
Cylinder(d=od, l=l, CENTER),
Cylinder(d=id, l=l+1, CENTER)
),
children
)
The benefits could be massive:
- Variables are mutable.
- You can store geometry in a variable.
- use/include gets replaced by import, which is less buggy.
- Efficient data structures like Dictionaries and Classes are available.
- You can assign multiple variables from a tuple returned from a
function/module. - You can actually read and parse files from disk.
- You can import C and Fortran based geometry libraries like
ClipperLib and use them directly. (Via Cython if needed) - You can use Cython for code speed-ups.
- There’s a massive pre-existing set of libraries available for all
kinds of things. - You would be able to force-render some geometry early to get
bounds, vertices, faces, etc. - The Python language has had built-in support for function literals
for a long time now. - And much more.
It should be fairly easy to make Python equivalents of all the
OpenSCAD language functions and modules, and have them use Cython to
call into the same back-end calls that the OpenSCAD language currently
calls into. You can keep the current Scintilla editor and rendering GUI.
I would already have written this, except I KEEP swearing to myself
that I am NOT going to take on yet another project that I need to
support for 20 years.
- Revar
On Nov 24, 2020, at 2:36 AM, nop head <nop.head@gmail.com
mailto:nop.head@gmail.com> wrote:
It is easy to handle OPENSCADPATH in Python, including the platform
difference:
os.environ['OPENSCADPATH'].split(os.pathsep)
Gives you a list of paths to look in for libraries.
os.pathsep is ';' for Windows and ':' for others.
To remove some of the warnings about argument tokens I factored out
some common sub-expressions into variables. So perhaps there should
be a warning about repeated subexpressions.
On Tue, 24 Nov 2020 at 00:40, julianstirling
<julian@julianstirling.co.uk mailto:julian@julianstirling.co.uk> wrote:
"Correct. But then, there's the option to just not use those. " -
I can make
the linter shouty if you use them :D. I plan eventually to have a
configurable regex for nice variable names/module names/function
names.
@nophead
I did not push out the promised fix today. Busy busy busy. Still
working at
past midnight on something else.
Thanks for the double loop bug. Yeah I treat them the same as I
would key
word arguments. I can fix that.
Ah I do not check "OPENSCADPATH". I shall look into this. Will
probably be
weird to get it platform independent, but I am on linux you are
on windows
so I may have to carry on using you as an alpha tester.
Totally agree about the token counting being dumb. It is in there
for my own
purposes as I am cleaning up messy code and so it gives me a
sniff of where
to look. But yeah, need to think about complexity in a more
intelligent way.
Especially as any decent size list gets flagged! I was thinking
of adding
the complexity largest two elements in the list. This way it
represents a
list being more complex than a single token, but doesn't scale
stupidly.
--
Sent from: http://forum.openscad.org/ <http://forum.openscad.org/>
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
<http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org>
OpenSCAD mailing list
Discuss@lists.openscad.org mailto:Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org