NH
nop head
Wed, Feb 20, 2019 8:19 PM
This is not sufficient. In my original case I had $fn=8 and that resulted
in my model being unprintable due to the discrepancy.
Oh yes, spheres are a bit broken. Here you can see that a circle of radius
10 has its vertices exactly on 10.
[image: image.png]
But sphere doesn't get the poles and the equator correct as it starts the
latitude circles half an angle out. So yes dividing the cos(180 / $fn)
fixes it.
[image: image.png]
Alternatively, writing ones own with polyhedron is probably better.
I always learn from this forum.
I assume there's some reason it missing. It is impossible, right?
All modules currently can only return one child even though they can have
more than one child themselves. It is an implementation limitation and may
change. There is even a pull request for a version of for with union =
false as an option. https://github.com/openscad/openscad/pull/2796
On Wed, 20 Feb 2019 at 19:38, Hugo Jackson hugo@apres.net wrote:
I think the greatest handicap OpenSCAD faces is the vicious circle of
popularity vs. participation. I believe I read somewhere that you can count
on one hand the number of people who’ve taken on the task of OpenSCAD
development and maintenance… and as a consequence there are far more
features and functionality that end users would like to see than there are
people who have the time and resources to implement the wish lists.
As for my obligation to update the gear library, you make a good point. In
my defence while I occasionally see requests for “where to find a gear
library”, once they’re pointed to the existing contribution then that’s
usually the end of it, so my assumption is that the existing library is
giving people the functionality they need and no necessity to muddy the
water with my own contribution. But perhaps it's simply that the existing
library failed to meet their needs and they moved on in frustration.
But you’re right, it would be good to have more community endorsed
libraries, and if I were to make a suggestion to the OpenSCAD maintainers
it would be have an explicit and separate area on GitHub for OpenSCAD
libraries. As it stands, its seems that the primary repository for OpenSCAD
libraries is Thingiverse. While I don’t feel up to the challenge of
modifying OpenSCAD itself, I’d be on board with supplying and participating
in the development of library routines written in OpenSCAD.
The way to get rounded corners with the correct dimensions is to make
$fn is a multiple of 4. That way the circle or sphere has vertices that
align with the axes.
This is not sufficient. In my original case I had $fn=8 and that
in my model being unprintable due to the discrepancy. In 2d forcing
works. But in 3d, you have to force $fn=4 and you also have to correct
radius by the cos(180/$fn) factor. At least, I think that works. I
have a mechanism for making sure that my code is actually correct.
I should try to read the STL files.)
module boundcube(x,y,z,r=0,facets=20)
{
if (r==0)
translate([x[0],y[0],z[0]])
cube(size=[x[1]-x[0],y[1]-y[0],z[1]-z[0]],center=false);
else {
fixfacets = ceil(facets/4)*4; // Force facets to a multiple of 4
fixr = r/cos(180/facets);
hull()
for(i=[0,1])
for(j=[0,1])
for(k=[0,1])
translate([x[i]-2*i*r+r, y[j]-2*j*r+r, z[k]-2*k*r+r])
sphere(r=fixr, $fn=fixfacets);
}
}
If you know what you're doing ahead of time, so to speak, then I think
easier to build roundovers into the design. In the cases I'm thinking
constructed a model using a series of operations and then wanted the
to have a roundover. In once case, the model was fairly simple,
from the intersection of cubes. So I could have worked out the
the cube faces to figure out their intersections and hence determined the
line of intersection and then placed my roundover there. But in the
case, I started with a shape made from a cos wave joined up to a tangent
function, which I expanded using offset() and then extruded into 3d, and
then I used minkowski to turn it into a hollow shape with thin walls.
want to cut off and round over some of those walls. Figuring out exactly
where those walls are so I can round them over doesn't appear to be
forward, and I created a roundover shape and then shifted it around by
and error, which makes the model less parametric than one might like. I
considered the goal of rounding over the entire edge of the shape, which
follows a cos wave---except not quite because of the offset. I have no
how that could be accomplished short of redoing the model in a fully
functional (mathematical) fashion using polyhedron(), or trying to apply
minkowski again on it. It was slow enough with one minkowski. A more
general issue with minkowski is the need to design the model undersized
make it work. In one recent design I was making a box with cylinderical
holes and wanted the edge of the box and also the edges of the holes to
a roundover. I did this by subtracting cylinders from the cube, running
minkowski, and then subtracting the cylinders again to remove the
This seems sort of messy. But trying to construct roundover cylinders
seemed messier. And of course it happens that you want to round over
parts of the model, which minowski cannot do.
In response to Hugo Jackson, wouldn't it be better to extend the Gear
library to remove its limitations in a new library version rather than to
rewrite it yourself, for your own private version? I suppose there's
always the risk of things getting overwhelmingly complex due to special
situations. But if the OpenSCAD community regards libraries as method
tutorials rather than as building blocks it seems like we're never going
build very high. And if its the nature of OpenSCAD that you can't build
top of libraries but always need to rewrite them, that seems
suggests that the environment is fundamentally limited, that it has a
flaw of some kind. Or maybe the library design isn't good. But then we
need to know how to write a good, extensible library.
It would seem perfectly reasonable for OpenSCAD to provide primitive
operations like cylinder() but for there to be a set of standard
that provide things like adjustment for the polygonal nature of
But why should everybody have to (1) figure out the need for this and
(2) write it himself?
Every time I do a design I feel like I'm stumbling around trying to find
clean or elegant solutions to problem in the design. It doesn't really
like I should be trying to crowdsource my modeling by posting all of
problems here. That's also inefficient for the community in general. I
normally figure that when encountering a programming difficulty one
reduce it to the essential minimal example, but that seems harder to do
in other programming contexts. Or the minimal examples are bigger.
>
> This is not sufficient. In my original case I had $fn=8 and that resulted
> in my model being unprintable due to the discrepancy.
Oh yes, spheres are a bit broken. Here you can see that a circle of radius
10 has its vertices exactly on 10.
[image: image.png]
But sphere doesn't get the poles and the equator correct as it starts the
latitude circles half an angle out. So yes dividing the cos(180 / $fn)
fixes it.
[image: image.png]
Alternatively, writing ones own with polyhedron is probably better.
I always learn from this forum.
I assume there's some reason it missing. It is impossible, right?
All modules currently can only return one child even though they can have
more than one child themselves. It is an implementation limitation and may
change. There is even a pull request for a version of for with union =
false as an option. https://github.com/openscad/openscad/pull/2796
On Wed, 20 Feb 2019 at 19:38, Hugo Jackson <hugo@apres.net> wrote:
> I think the greatest handicap OpenSCAD faces is the vicious circle of
> popularity vs. participation. I believe I read somewhere that you can count
> on one hand the number of people who’ve taken on the task of OpenSCAD
> development and maintenance… and as a consequence there are far more
> features and functionality that end users would like to see than there are
> people who have the time and resources to implement the wish lists.
> As for my obligation to update the gear library, you make a good point. In
> my defence while I occasionally see requests for “where to find a gear
> library”, once they’re pointed to the existing contribution then that’s
> usually the end of it, so my assumption is that the existing library is
> giving people the functionality they need and no necessity to muddy the
> water with my own contribution. But perhaps it's simply that the existing
> library failed to meet their needs and they moved on in frustration.
> But you’re right, it would be good to have more community endorsed
> libraries, and if I were to make a suggestion to the OpenSCAD maintainers
> it would be have an explicit and separate area on GitHub for OpenSCAD
> libraries. As it stands, its seems that the primary repository for OpenSCAD
> libraries is Thingiverse. While I don’t feel up to the challenge of
> modifying OpenSCAD itself, I’d be on board with supplying and participating
> in the development of library routines written in OpenSCAD.
>
> > On Feb 20, 2019, at 10:55 AM, adrianv <avm4@cornell.edu> wrote:
> >
> > nophead wrote
> >> The way to get rounded corners with the correct dimensions is to make
> sure
> >> $fn is a multiple of 4. That way the circle or sphere has vertices that
> >> align with the axes.
> >
> > This is not sufficient. In my original case I had $fn=8 and that
> resulted
> > in my model being unprintable due to the discrepancy. In 2d forcing
> $fn=4
> > works. But in 3d, you have to force $fn=4 and you also have to correct
> the
> > radius by the cos(180/$fn) factor. At least, I think that works. I
> don't
> > have a mechanism for making sure that my code is actually correct.
> (Maybe
> > I should try to read the STL files.)
> >
> > module boundcube(x,y,z,r=0,facets=20)
> > {
> > if (r==0)
> > translate([x[0],y[0],z[0]])
> > cube(size=[x[1]-x[0],y[1]-y[0],z[1]-z[0]],center=false);
> > else {
> > fixfacets = ceil(facets/4)*4; // Force facets to a multiple of 4
>
> > fixr = r/cos(180/facets);
> > hull()
> > for(i=[0,1])
> > for(j=[0,1])
> > for(k=[0,1])
> > translate([x[i]-2*i*r+r, y[j]-2*j*r+r, z[k]-2*k*r+r])
> > sphere(r=fixr, $fn=fixfacets);
> > }
> > }
> >
> > If you know what you're doing ahead of time, so to speak, then I think
> it's
> > easier to build roundovers into the design. In the cases I'm thinking
> of I
> > constructed a model using a series of operations and then wanted the
> result
> > to have a roundover. In once case, the model was fairly simple,
> resulting
> > from the intersection of cubes. So I could have worked out the
> equations of
> > the cube faces to figure out their intersections and hence determined the
> > line of intersection and then placed my roundover there. But in the
> second
> > case, I started with a shape made from a cos wave joined up to a tangent
> > function, which I expanded using offset() and then extruded into 3d, and
> > then I used minkowski to turn it into a hollow shape with thin walls.
> Now I
> > want to cut off and round over some of those walls. Figuring out exactly
> > where those walls are so I can round them over doesn't appear to be
> straight
> > forward, and I created a roundover shape and then shifted it around by
> trial
> > and error, which makes the model less parametric than one might like. I
> > considered the goal of rounding over the entire edge of the shape, which
> > follows a cos wave---except not quite because of the offset. I have no
> idea
> > how that could be accomplished short of redoing the model in a fully
> > functional (mathematical) fashion using polyhedron(), or trying to apply
> > minkowski again on it. It was slow enough with one minkowski. A more
> > general issue with minkowski is the need to design the model undersized
> to
> > make it work. In one recent design I was making a box with cylinderical
> > holes and wanted the edge of the box and also the edges of the holes to
> have
> > a roundover. I did this by subtracting cylinders from the cube, running
> > minkowski, and then subtracting the cylinders again to remove the
> excess.
> > This seems sort of messy. But trying to construct roundover cylinders
> > seemed messier. And of course it happens that you want to round over
> just
> > parts of the model, which minowski cannot do.
> >
> > In response to Hugo Jackson, wouldn't it be better to extend the Gear
> > library to remove its limitations in a new library version rather than to
> > rewrite it yourself, for your own private version? I suppose there's
> > always the risk of things getting overwhelmingly complex due to special
> case
> > situations. But if the OpenSCAD community regards libraries as method
> > tutorials rather than as building blocks it seems like we're never going
> to
> > build very high. And if its the nature of OpenSCAD that you can't build
> on
> > top of libraries but always need to rewrite them, that seems
> disturbing. It
> > suggests that the environment is fundamentally limited, that it has a
> design
> > flaw of some kind. Or maybe the library design isn't good. But then we
> > need to know how to write a good, extensible library.
> >
> > It would seem perfectly reasonable for OpenSCAD to provide primitive
> > operations like cylinder() but for there to be a set of standard
> libraries
> > that provide things like adjustment for the polygonal nature of
> cylinders.
> > But why should everybody have to (1) figure out the need for this and
> then
> > (2) write it himself?
> >
> > Every time I do a design I feel like I'm stumbling around trying to find
> > clean or elegant solutions to problem in the design. It doesn't really
> seem
> > like I should be trying to crowdsource my modeling by posting all of
> these
> > problems here. That's also inefficient for the community in general. I
> > normally figure that when encountering a programming difficulty one
> should
> > reduce it to the essential minimal example, but that seems harder to do
> than
> > in other programming contexts. Or the minimal examples are bigger.
> Maybe
> > I just need to work harder at the reduction.
> >
> >
> >
> >
> > --
> > Sent from: http://forum.openscad.org/
> >
> > _______________________________________________
> > OpenSCAD mailing list
> > 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
>
JF
Joe Francis
Wed, Feb 20, 2019 8:32 PM
OpenSCAD has a weird relationship with libraries. I think there's
fundamentally 2 problems that feed each other.
1) No package manager has ever really gained much adoption. (I've tried
2) There's not a lot of community knowledge on how to make a library
that is well suited for reuse (or extract one from a larger project).
There's definitely a bootstrapping problem here. I personally think a
lot of the perceived limitations of OpenSCAD can be solved at the
library level, and having a more compelling ecosystem there will attract
more effort in OpenSCAD itself.
I haven't spent much time on scad_bundler recently because I never got
much interest or engagement on it - good bad or otherwise. Perhaps
there's a mismatch in that I'm trying to approach using OpenSCAD like a
software engineering problem, and maybe that's not where the community
is at. At the same time, "post your library on thingiverse" hasn't
really taken off, either.
I'm not sure what the next step is, but I'm open to suggestions.
On 2/20/19 1:37 PM, Hugo Jackson wrote:
I think the greatest handicap OpenSCAD faces is the vicious circle of popularity vs. participation. I believe I read somewhere that you can count on one hand the number of people who’ve taken on the task of OpenSCAD development and maintenance… and as a consequence there are far more features and functionality that end users would like to see than there are people who have the time and resources to implement the wish lists.
As for my obligation to update the gear library, you make a good point. In my defence while I occasionally see requests for “where to find a gear library”, once they’re pointed to the existing contribution then that’s usually the end of it, so my assumption is that the existing library is giving people the functionality they need and no necessity to muddy the water with my own contribution. But perhaps it's simply that the existing library failed to meet their needs and they moved on in frustration.
But you’re right, it would be good to have more community endorsed libraries, and if I were to make a suggestion to the OpenSCAD maintainers it would be have an explicit and separate area on GitHub for OpenSCAD libraries. As it stands, its seems that the primary repository for OpenSCAD libraries is Thingiverse. While I don’t feel up to the challenge of modifying OpenSCAD itself, I’d be on board with supplying and participating in the development of library routines written in OpenSCAD.
The way to get rounded corners with the correct dimensions is to make sure
$fn is a multiple of 4. That way the circle or sphere has vertices that
align with the axes.
This is not sufficient. In my original case I had $fn=8 and that resulted
in my model being unprintable due to the discrepancy. In 2d forcing $fn=4
works. But in 3d, you have to force $fn=4 and you also have to correct the
radius by the cos(180/$fn) factor. At least, I think that works. I don't
have a mechanism for making sure that my code is actually correct. (Maybe
I should try to read the STL files.)
module boundcube(x,y,z,r=0,facets=20)
{
if (r==0)
translate([x[0],y[0],z[0]])
cube(size=[x[1]-x[0],y[1]-y[0],z[1]-z[0]],center=false);
else {
fixfacets = ceil(facets/4)4; // Force facets to a multiple of 4
fixr = r/cos(180/facets);
hull()
for(i=[0,1])
for(j=[0,1])
for(k=[0,1])
translate([x[i]-2ir+r, y[j]-2jr+r, z[k]-2k*r+r])
sphere(r=fixr, $fn=fixfacets);
}
}
If you know what you're doing ahead of time, so to speak, then I think it's
easier to build roundovers into the design. In the cases I'm thinking of I
constructed a model using a series of operations and then wanted the result
to have a roundover. In once case, the model was fairly simple, resulting
from the intersection of cubes. So I could have worked out the equations of
the cube faces to figure out their intersections and hence determined the
line of intersection and then placed my roundover there. But in the second
case, I started with a shape made from a cos wave joined up to a tangent
function, which I expanded using offset() and then extruded into 3d, and
then I used minkowski to turn it into a hollow shape with thin walls. Now I
want to cut off and round over some of those walls. Figuring out exactly
where those walls are so I can round them over doesn't appear to be straight
forward, and I created a roundover shape and then shifted it around by trial
and error, which makes the model less parametric than one might like. I
considered the goal of rounding over the entire edge of the shape, which
follows a cos wave---except not quite because of the offset. I have no idea
how that could be accomplished short of redoing the model in a fully
functional (mathematical) fashion using polyhedron(), or trying to apply
minkowski again on it. It was slow enough with one minkowski. A more
general issue with minkowski is the need to design the model undersized to
make it work. In one recent design I was making a box with cylinderical
holes and wanted the edge of the box and also the edges of the holes to have
a roundover. I did this by subtracting cylinders from the cube, running
minkowski, and then subtracting the cylinders again to remove the excess.
This seems sort of messy. But trying to construct roundover cylinders
seemed messier. And of course it happens that you want to round over just
parts of the model, which minowski cannot do.
In response to Hugo Jackson, wouldn't it be better to extend the Gear
library to remove its limitations in a new library version rather than to
rewrite it yourself, for your own private version? I suppose there's
always the risk of things getting overwhelmingly complex due to special case
situations. But if the OpenSCAD community regards libraries as method
tutorials rather than as building blocks it seems like we're never going to
build very high. And if its the nature of OpenSCAD that you can't build on
top of libraries but always need to rewrite them, that seems disturbing. It
suggests that the environment is fundamentally limited, that it has a design
flaw of some kind. Or maybe the library design isn't good. But then we
need to know how to write a good, extensible library.
It would seem perfectly reasonable for OpenSCAD to provide primitive
operations like cylinder() but for there to be a set of standard libraries
that provide things like adjustment for the polygonal nature of cylinders.
But why should everybody have to (1) figure out the need for this and then
(2) write it himself?
Every time I do a design I feel like I'm stumbling around trying to find
clean or elegant solutions to problem in the design. It doesn't really seem
like I should be trying to crowdsource my modeling by posting all of these
problems here. That's also inefficient for the community in general. I
normally figure that when encountering a programming difficulty one should
reduce it to the essential minimal example, but that seems harder to do than
in other programming contexts. Or the minimal examples are bigger. Maybe
I just need to work harder at the reduction.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD has a weird relationship with libraries. I think there's
fundamentally 2 problems that feed each other.
1) No package manager has ever really gained much adoption. (I've tried
- I'm the author of https://github.com/lostapathy/scad_bundler). Which
probably makes sense because there aren't many libraries packaged for
any package manager.
2) There's not a lot of community knowledge on how to make a library
that is well suited for reuse (or extract one from a larger project).
There's definitely a bootstrapping problem here. I personally think a
lot of the perceived limitations of OpenSCAD can be solved at the
library level, and having a more compelling ecosystem there will attract
more effort in OpenSCAD itself.
I haven't spent much time on scad_bundler recently because I never got
much interest or engagement on it - good bad or otherwise. Perhaps
there's a mismatch in that I'm trying to approach using OpenSCAD like a
software engineering problem, and maybe that's not where the community
is at. At the same time, "post your library on thingiverse" hasn't
really taken off, either.
I'm not sure what the next step is, but I'm open to suggestions.
On 2/20/19 1:37 PM, Hugo Jackson wrote:
> I think the greatest handicap OpenSCAD faces is the vicious circle of popularity vs. participation. I believe I read somewhere that you can count on one hand the number of people who’ve taken on the task of OpenSCAD development and maintenance… and as a consequence there are far more features and functionality that end users would like to see than there are people who have the time and resources to implement the wish lists.
> As for my obligation to update the gear library, you make a good point. In my defence while I occasionally see requests for “where to find a gear library”, once they’re pointed to the existing contribution then that’s usually the end of it, so my assumption is that the existing library is giving people the functionality they need and no necessity to muddy the water with my own contribution. But perhaps it's simply that the existing library failed to meet their needs and they moved on in frustration.
> But you’re right, it would be good to have more community endorsed libraries, and if I were to make a suggestion to the OpenSCAD maintainers it would be have an explicit and separate area on GitHub for OpenSCAD libraries. As it stands, its seems that the primary repository for OpenSCAD libraries is Thingiverse. While I don’t feel up to the challenge of modifying OpenSCAD itself, I’d be on board with supplying and participating in the development of library routines written in OpenSCAD.
>
>> On Feb 20, 2019, at 10:55 AM, adrianv <avm4@cornell.edu> wrote:
>>
>> nophead wrote
>>> The way to get rounded corners with the correct dimensions is to make sure
>>> $fn is a multiple of 4. That way the circle or sphere has vertices that
>>> align with the axes.
>> This is not sufficient. In my original case I had $fn=8 and that resulted
>> in my model being unprintable due to the discrepancy. In 2d forcing $fn=4
>> works. But in 3d, you have to force $fn=4 and you also have to correct the
>> radius by the cos(180/$fn) factor. At least, I think that works. I don't
>> have a mechanism for making sure that my code is actually correct. (Maybe
>> I should try to read the STL files.)
>>
>> module boundcube(x,y,z,r=0,facets=20)
>> {
>> if (r==0)
>> translate([x[0],y[0],z[0]])
>> cube(size=[x[1]-x[0],y[1]-y[0],z[1]-z[0]],center=false);
>> else {
>> fixfacets = ceil(facets/4)*4; // Force facets to a multiple of 4
>> fixr = r/cos(180/facets);
>> hull()
>> for(i=[0,1])
>> for(j=[0,1])
>> for(k=[0,1])
>> translate([x[i]-2*i*r+r, y[j]-2*j*r+r, z[k]-2*k*r+r])
>> sphere(r=fixr, $fn=fixfacets);
>> }
>> }
>>
>> If you know what you're doing ahead of time, so to speak, then I think it's
>> easier to build roundovers into the design. In the cases I'm thinking of I
>> constructed a model using a series of operations and then wanted the result
>> to have a roundover. In once case, the model was fairly simple, resulting
>> from the intersection of cubes. So I could have worked out the equations of
>> the cube faces to figure out their intersections and hence determined the
>> line of intersection and then placed my roundover there. But in the second
>> case, I started with a shape made from a cos wave joined up to a tangent
>> function, which I expanded using offset() and then extruded into 3d, and
>> then I used minkowski to turn it into a hollow shape with thin walls. Now I
>> want to cut off and round over some of those walls. Figuring out exactly
>> where those walls are so I can round them over doesn't appear to be straight
>> forward, and I created a roundover shape and then shifted it around by trial
>> and error, which makes the model less parametric than one might like. I
>> considered the goal of rounding over the entire edge of the shape, which
>> follows a cos wave---except not quite because of the offset. I have no idea
>> how that could be accomplished short of redoing the model in a fully
>> functional (mathematical) fashion using polyhedron(), or trying to apply
>> minkowski again on it. It was slow enough with one minkowski. A more
>> general issue with minkowski is the need to design the model undersized to
>> make it work. In one recent design I was making a box with cylinderical
>> holes and wanted the edge of the box and also the edges of the holes to have
>> a roundover. I did this by subtracting cylinders from the cube, running
>> minkowski, and then subtracting the cylinders again to remove the excess.
>> This seems sort of messy. But trying to construct roundover cylinders
>> seemed messier. And of course it happens that you want to round over just
>> parts of the model, which minowski cannot do.
>>
>> In response to Hugo Jackson, wouldn't it be better to extend the Gear
>> library to remove its limitations in a new library version rather than to
>> rewrite it yourself, for your own private version? I suppose there's
>> always the risk of things getting overwhelmingly complex due to special case
>> situations. But if the OpenSCAD community regards libraries as method
>> tutorials rather than as building blocks it seems like we're never going to
>> build very high. And if its the nature of OpenSCAD that you can't build on
>> top of libraries but always need to rewrite them, that seems disturbing. It
>> suggests that the environment is fundamentally limited, that it has a design
>> flaw of some kind. Or maybe the library design isn't good. But then we
>> need to know how to write a good, extensible library.
>>
>> It would seem perfectly reasonable for OpenSCAD to provide primitive
>> operations like cylinder() but for there to be a set of standard libraries
>> that provide things like adjustment for the polygonal nature of cylinders.
>> But why should everybody have to (1) figure out the need for this and then
>> (2) write it himself?
>>
>> Every time I do a design I feel like I'm stumbling around trying to find
>> clean or elegant solutions to problem in the design. It doesn't really seem
>> like I should be trying to crowdsource my modeling by posting all of these
>> problems here. That's also inefficient for the community in general. I
>> normally figure that when encountering a programming difficulty one should
>> reduce it to the essential minimal example, but that seems harder to do than
>> in other programming contexts. Or the minimal examples are bigger. Maybe
>> I just need to work harder at the reduction.
>>
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> 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
>
A
adrianv
Wed, Feb 20, 2019 10:38 PM
This is not sufficient. In my original case I had $fn=8 and that
resulted
in my model being unprintable due to the discrepancy.
Oh yes, spheres are a bit broken. Here you can see that a circle of radius
10 has its vertices exactly on 10.
[image: image.png]
Actually all I can tell from that picture is that the circle is close to 10.
I can't tell that it's exactly ten. Could be 10.1 maybe. Could it be 10.2?
Maybe.
I went ahead and looked at the STL for
linear_extrude(height=1)circle(r=1,$fn=8); and found that it looks like
this:
solid OpenSCAD_Model
facet normal 0 0 -1
outer loop
vertex 0.707107 0.707107 0
vertex 1 0 0
vertex 0.707107 -0.707107 0
endloop
endfacet
facet normal -0 -0 -1
outer loop
vertex 0.707107 0.707107 0
vertex 0.707107 -0.707107 0
vertex -0.707107 0.707107 0
endloop
endfacet
facet normal 0 0 -1
outer loop
vertex 0.707107 0.707107 0
vertex -0.707107 0.707107 0
vertex 6.12323e-17 1 0
endloop
endfacet
facet normal 0 -0 -1
outer loop
vertex -0.707107 0.707107 0
vertex -1.83697e-16 -1 0
vertex -1 1.22465e-16 0
endloop
endfacet
etc, etc, etc
I loaded the data into octave and checked that the x and y range from -1 to
1 and that furthermore, all values above 0.9 are equal to 1 and all values
below -0.9 are less than 1. So that's confirmation that nothing surprising
has happened. I suppose I ought to do the same thing for my boundcube()
module.
--
Sent from: http://forum.openscad.org/
nophead wrote
>>
>> This is not sufficient. In my original case I had $fn=8 and that
>> resulted
>> in my model being unprintable due to the discrepancy.
>
>
> Oh yes, spheres are a bit broken. Here you can see that a circle of radius
> 10 has its vertices exactly on 10.
>
> [image: image.png]
Actually all I can tell from that picture is that the circle is close to 10.
I can't tell that it's exactly ten. Could be 10.1 maybe. Could it be 10.2?
Maybe.
I went ahead and looked at the STL for
linear_extrude(height=1)circle(r=1,$fn=8); and found that it looks like
this:
solid OpenSCAD_Model
facet normal 0 0 -1
outer loop
vertex 0.707107 0.707107 0
vertex 1 0 0
vertex 0.707107 -0.707107 0
endloop
endfacet
facet normal -0 -0 -1
outer loop
vertex 0.707107 0.707107 0
vertex 0.707107 -0.707107 0
vertex -0.707107 0.707107 0
endloop
endfacet
facet normal 0 0 -1
outer loop
vertex 0.707107 0.707107 0
vertex -0.707107 0.707107 0
vertex 6.12323e-17 1 0
endloop
endfacet
facet normal 0 -0 -1
outer loop
vertex -0.707107 0.707107 0
vertex -1.83697e-16 -1 0
vertex -1 1.22465e-16 0
endloop
endfacet
etc, etc, etc
I loaded the data into octave and checked that the x and y range from -1 to
1 and that furthermore, all values above 0.9 are equal to 1 and all values
below -0.9 are less than 1. So that's confirmation that nothing surprising
has happened. I suppose I ought to do the same thing for my boundcube()
module.
--
Sent from: http://forum.openscad.org/
M
MichaelAtOz
Wed, Feb 20, 2019 10:45 PM
OpenSCAD has a weird relationship with libraries.
1) No package manager has ever really gained much adoption
2) There's not a lot of community knowledge on how to make a library
- The language needs additional features to better support libraries. e.g.
Namespaces
There has been much discussion on the future direction of OpenSCAD including
many such features, see here
https://github.com/openscad/openscad/wiki/OpenSCAD-Enhancement-Proposals
& here https://github.com/doug-moen/openscad2/blob/master/README.md for
example, plus much past discussion in the headspace of the development
community. Note that they are proposals and still need design work (IMHO)
and not necessarily fully endorsed direction.
But as Hugo mentions, there is only a small pool of spare-time developers,
the resources available vary, so progress has to go in baby steps. An
unfortunate reality.
It should also be noted that OpenSCAD is young, according to Wikipedia, the
initial release was 19 February 2010. Happy 9th Birthday!! And only really 4
major releases in that time, with the 5th hopefully soon.
Compare to 47 years for C, or 29 for Python, I imaging the early versions
were also clunky.
Admin - email* me if you need anything, or if I've done something stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Sent from: http://forum.openscad.org/
lostapathy wrote
> OpenSCAD has a weird relationship with libraries.
> 1) No package manager has ever really gained much adoption
>
> 2) There's not a lot of community knowledge on how to make a library
3) The language needs additional features to better support libraries. e.g.
Namespaces
There has been much discussion on the future direction of OpenSCAD including
many such features, see here
<https://github.com/openscad/openscad/wiki/OpenSCAD-Enhancement-Proposals>
& here <https://github.com/doug-moen/openscad2/blob/master/README.md> for
example, plus much past discussion in the headspace of the development
community. Note that they are proposals and still need design work (IMHO)
and not necessarily fully endorsed direction.
But as Hugo mentions, there is only a small pool of spare-time developers,
the resources available vary, so progress has to go in baby steps. An
unfortunate reality.
It should also be noted that OpenSCAD is young, according to Wikipedia, the
initial release was 19 February 2010. Happy 9th Birthday!! And only really 4
major releases in that time, with the 5th hopefully soon.
Compare to 47 years for C, or 29 for Python, I imaging the early versions
were also clunky.
-----
Admin - email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
--
Sent from: http://forum.openscad.org/
JB
Jordan Brown
Wed, Feb 20, 2019 10:50 PM
On 2/20/2019 11:32 AM, adrianv wrote:
On 2/20/2019 4:59 AM, adrianv wrote:
Of course one can say you learn what you need to in order to make the
design
you're trying to make. But it wasn't apparent to me, for example, the
way
that modules could use children and what (some of) the implications are.
Yes. That tutorial was what opened my eyes to this whole capability. But I
had to stumble across it.
If you go to openscad.org, then "documentation", then (in the left
sidebar or scroll down), "Tutorials - Articles / Blogs", it's the first
link. It was the first thing I saw and read. It could be more
prominent, but not much.
It also raises the question about applying my own
module to a loop when they describe how their chained_hull() module won't
work on the output of for(), since for() just produces one child. That's
what caused me to ask the question about whether I can write my own for()
function. Certainly the code example where he hard codes the wedge_if calls
in a big list seems pretty darn ugly. Is that the best that is possible?
It seems like being able to write my own iteration, or to operate on the
separate children of a for loop, would be a useful feature. I assume
there's some reason it missing. It is impossible, right?
As nop head said, a module can only return one child.
Note: I recognize what can be done with matrix transformations. I'm just
not seeing (at the moment) an application for it. And if it's only good for
making skews, really, then it seems like you really just want to write the
skew() module and never look at mulmatrix again, due to its increased
complexity.
Other than general DIY matrixes, skewing is the only application I know
of. Indeed, I wrote a skew module to wrap it. I haven't thought enough
about it to know whether one function is enough, or if you need more
than one. If you try to do it with only one, I suspect that you end up
having to pass six values to fully describe the skew. (But non-trivial
skews hurt my brain.)
I suspect that much of the reason for it is that the other functions
require the capability, so why not expose it in case somebody finds it
useful?
I saw in another message somebody searching vertex lists with search() for
some purpose that I didn't fully understand. Lookup tables on single
characters seems like a pretty contrived example.
Well... it was the answer to a question that somebody really asked, so
not totally contrived. I don't remember exactly what they were looking
for, but it involved getting character spacing right. (A further
enhancement along the same lines might do searches on character pairs
for kerning.)
I have used the somewhat-similar lookup( ) in my own work to do
interpolated lookups in a table.
On 2/20/2019 11:32 AM, adrianv wrote:
> JordanBrown wrote
>> On 2/20/2019 4:59 AM, adrianv wrote:
>>> Of course one can say you learn what you need to in order to make the
>>> design
>>> you're trying to make. But it wasn't apparent to me, for example, the
>>> way
>>> that modules could use children and what (some of) the implications are.
>>
>> Have you read this tutorial?
>>
>> http://www.tridimake.com/2014/09/how-to-use-openscad-tricks-and-tips-to.html
>>
>> It covers children in section 4.
> Yes. That tutorial was what opened my eyes to this whole capability. But I
> had to stumble across it.
If you go to openscad.org, then "documentation", then (in the left
sidebar or scroll down), "Tutorials - Articles / Blogs", it's the first
link. It was the first thing I saw and read. It could be more
prominent, but not much.
> It also raises the question about applying my own
> module to a loop when they describe how their chained_hull() module won't
> work on the output of for(), since for() just produces one child. That's
> what caused me to ask the question about whether I can write my own for()
> function. Certainly the code example where he hard codes the wedge_if calls
> in a big list seems pretty darn ugly. Is that the best that is possible?
> It seems like being able to write my own iteration, or to operate on the
> separate children of a for loop, would be a useful feature. I assume
> there's some reason it missing. It is impossible, right?
As nop head said, a module can only return one child.
> Note: I recognize what can be done with matrix transformations. I'm just
> not seeing (at the moment) an application for it. And if it's only good for
> making skews, really, then it seems like you really just want to write the
> skew() module and never look at mulmatrix again, due to its increased
> complexity.
Other than general DIY matrixes, skewing is the only application I know
of. Indeed, I wrote a skew module to wrap it. I haven't thought enough
about it to know whether one function is enough, or if you need more
than one. If you try to do it with only one, I suspect that you end up
having to pass six values to fully describe the skew. (But non-trivial
skews hurt my brain.)
I suspect that much of the reason for it is that the other functions
require the capability, so why not expose it in case somebody finds it
useful?
> I saw in another message somebody searching vertex lists with search() for
> some purpose that I didn't fully understand. Lookup tables on single
> characters seems like a pretty contrived example.
Well... it *was* the answer to a question that somebody really asked, so
not totally contrived. I don't remember exactly what they were looking
for, but it involved getting character spacing right. (A further
enhancement along the same lines might do searches on character pairs
for kerning.)
I have used the somewhat-similar lookup( ) in my own work to do
interpolated lookups in a table.
JF
Joe Francis
Wed, Feb 20, 2019 11:06 PM
On 2/20/19 4:45 PM, MichaelAtOz wrote:
OpenSCAD has a weird relationship with libraries.
1) No package manager has ever really gained much adoption
2) There's not a lot of community knowledge on how to make a library
I'm quite familiar with that discussion at the info on GitHub.
I'm not saying there isn't room for language improvement, but IME you
can go a long on libraries without namespaces. The scoping difference
of include vs use makes it possible to not pollute the namespace with
extra variables or modules. Libraries can be built such that a use'd
file only puts one module into the namespace of the caller, so you can
import only a minimum amount of functionality. Given that, I'm not sure
why calling a module as MyLibrary-Function() vs MyLibrary::Function() is
a show stopper.
But as Hugo mentions, there is only a small pool of spare-time developers,
the resources available vary, so progress has to go in baby steps. An
unfortunate reality.
I agree completely. My point was that if we build up the userspace
ecosystem around OpenSCAD to enable a larger user base, the small subset
of OpenSCAD users who can also develop on OpenSCAD itself will probably
grow with the community.
On 2/20/19 4:45 PM, MichaelAtOz wrote:
> lostapathy wrote
>> OpenSCAD has a weird relationship with libraries.
>> 1) No package manager has ever really gained much adoption
>>
>> 2) There's not a lot of community knowledge on how to make a library
> 3) The language needs additional features to better support libraries. e.g.
> Namespaces
>
> There has been much discussion on the future direction of OpenSCAD including
> many such features, see here
> <https://github.com/openscad/openscad/wiki/OpenSCAD-Enhancement-Proposals>
> & here <https://github.com/doug-moen/openscad2/blob/master/README.md> for
> example, plus much past discussion in the headspace of the development
> community. Note that they are proposals and still need design work (IMHO)
> and not necessarily fully endorsed direction.
I'm quite familiar with that discussion at the info on GitHub.
I'm not saying there isn't room for language improvement, but IME you
can go a long on libraries without namespaces. The scoping difference
of include vs use makes it possible to not pollute the namespace with
extra variables or modules. Libraries can be built such that a use'd
file only puts one module into the namespace of the caller, so you can
import only a minimum amount of functionality. Given that, I'm not sure
why calling a module as MyLibrary-Function() vs MyLibrary::Function() is
a show stopper.
> But as Hugo mentions, there is only a small pool of spare-time developers,
> the resources available vary, so progress has to go in baby steps. An
> unfortunate reality.
I agree completely. My point was that if we build up the userspace
ecosystem around OpenSCAD to enable a larger user base, the small subset
of OpenSCAD users who can also develop on OpenSCAD itself will probably
grow with the community.
A
adrianv
Wed, Feb 20, 2019 11:21 PM
I hadn't thought about the possible importance of having a package manager.
It looks like your project is a reasonable effort. I'm not sure it's enough
alone. To me it seems like the thing that will make packages successful is
a central authority that lists packages (so people can find them) and
documentation and tutorials about the packages. This last thing is crucial.
There is a list of packages in the manual, but the list is not very useful
because it doesn't state what exactly the packages can (or cannot) do. And
furthermore, the packages aren't well documented. And it comes across more
like a random collection of assorted code people wrote than an organized
extension to OpenSCAD. If a package is seen as a standard library you
should be able to find documentation about how to use it and what it does.
If you look up the C++ template classes, or NumPy, you don't have to read
the source code to figure out what they can do or how to use them. The
package are documented right along side the basic language. If the OpenSCAD
manual had a section on packages and actually documented them, then new
users would presumably be interested in getting and using the packages. I
updated my OpenSCAD from what is apparently the stable version (???) from 3
years ago to the development version because I read the manual and needed
those features. If I read about some package that would solve my problem
I'd install it. But there's nothing to read about....
I tried to use path_extrude on my recent project but had problems. Lack of
documentation made it unclear if they were solvable or not. Maybe I should
read the code. But looking at it now, I see that it starts at the ground
level, defining lots of very primitive operations that one might imagine
should be supplied in some standard way by lower level packages.
I think this also ties to the second point. If there are no libraries
designed for reuse then it's hard for users to know how to write such a
library. What I stumbled across were various piles of code that may (or may
not) be well designed code. I don't know. And I'm not sure what they do.
Where is my model for how to make a library? If I had example libraries
that were well documented it would provide ideas about how to design
additional libraries, I think. It also seems like there's a potential
issue with libraries including other libraries. Is it bad for a library to
be included multiple times in different scopes?
The "post your library on thingiverse" approach seems ridiculous to me. I
started running across stuff on thingiverse and it wasn't clear to me what
its status was. It's not where I'd expect to find a library---that's for
sure.
I'm not sure what the solution is---and obviously I just popped in here
today so I'm not really in a position to say what should happen. But it's
seeming more and more like the existing situation is problematic. Perhaps
we should start a well defined project of some kind to establish and
document a set of standard libraries?
lostapathy wrote
OpenSCAD has a weird relationship with libraries. I think there's
fundamentally 2 problems that feed each other.
1) No package manager has ever really gained much adoption. (I've tried
2) There's not a lot of community knowledge on how to make a library
that is well suited for reuse (or extract one from a larger project).
There's definitely a bootstrapping problem here. I personally think a
lot of the perceived limitations of OpenSCAD can be solved at the
library level, and having a more compelling ecosystem there will attract
more effort in OpenSCAD itself.
I haven't spent much time on scad_bundler recently because I never got
much interest or engagement on it - good bad or otherwise. Perhaps
there's a mismatch in that I'm trying to approach using OpenSCAD like a
software engineering problem, and maybe that's not where the community
is at. At the same time, "post your library on thingiverse" hasn't
really taken off, either.
I'm not sure what the next step is, but I'm open to suggestions.
I hadn't thought about the possible importance of having a package manager.
It looks like your project is a reasonable effort. I'm not sure it's enough
alone. To me it seems like the thing that will make packages successful is
a central authority that lists packages (so people can find them) and
documentation and tutorials about the packages. This last thing is crucial.
There is a list of packages in the manual, but the list is not very useful
because it doesn't state what exactly the packages can (or cannot) do. And
furthermore, the packages aren't well documented. And it comes across more
like a random collection of assorted code people wrote than an organized
extension to OpenSCAD. If a package is seen as a standard library you
should be able to find documentation about how to use it and what it does.
If you look up the C++ template classes, or NumPy, you don't have to read
the source code to figure out what they can do or how to use them. The
package are documented right along side the basic language. If the OpenSCAD
manual had a section on packages and actually documented them, then new
users would presumably be interested in getting and using the packages. I
updated my OpenSCAD from what is apparently the stable version (???) from 3
years ago to the development version because I read the manual and needed
those features. If I read about some package that would solve my problem
I'd install it. But there's nothing to read about....
I tried to use path_extrude on my recent project but had problems. Lack of
documentation made it unclear if they were solvable or not. Maybe I should
read the code. But looking at it now, I see that it starts at the ground
level, defining lots of very primitive operations that one might imagine
should be supplied in some standard way by lower level packages.
I think this also ties to the second point. If there are no libraries
designed for reuse then it's hard for users to know how to write such a
library. What I stumbled across were various piles of code that may (or may
not) be well designed code. I don't know. And I'm not sure what they do.
Where is my model for how to make a library? If I had example libraries
that were well documented it would provide ideas about how to design
additional libraries, I think. It also seems like there's a potential
issue with libraries including other libraries. Is it bad for a library to
be included multiple times in different scopes?
The "post your library on thingiverse" approach seems ridiculous to me. I
started running across stuff on thingiverse and it wasn't clear to me what
its status was. It's not where I'd expect to find a library---that's for
sure.
I'm not sure what the solution is---and obviously I just popped in here
today so I'm not really in a position to say what should happen. But it's
seeming more and more like the existing situation is problematic. Perhaps
we should start a well defined project of some kind to establish and
document a set of standard libraries?
lostapathy wrote
> OpenSCAD has a weird relationship with libraries. I think there's
> fundamentally 2 problems that feed each other.
>
> 1) No package manager has ever really gained much adoption. (I've tried
> - I'm the author of https://github.com/lostapathy/scad_bundler). Which
> probably makes sense because there aren't many libraries packaged for
> any package manager.
>
> 2) There's not a lot of community knowledge on how to make a library
> that is well suited for reuse (or extract one from a larger project).
>
> There's definitely a bootstrapping problem here. I personally think a
> lot of the perceived limitations of OpenSCAD can be solved at the
> library level, and having a more compelling ecosystem there will attract
> more effort in OpenSCAD itself.
>
> I haven't spent much time on scad_bundler recently because I never got
> much interest or engagement on it - good bad or otherwise. Perhaps
> there's a mismatch in that I'm trying to approach using OpenSCAD like a
> software engineering problem, and maybe that's not where the community
> is at. At the same time, "post your library on thingiverse" hasn't
> really taken off, either.
>
> I'm not sure what the next step is, but I'm open to suggestions.
--
Sent from: http://forum.openscad.org/
HJ
Hugo Jackson
Wed, Feb 20, 2019 11:37 PM
I suggest that a useful first step might be legitimizing what libraries are currently available by adding them to the OpenSCAD User Manual… as say Chapter 10. That way at least those are aren’t adverse to RTFM would see that libraries are not simply routines of unknown providence showing up on Thingiverse.
If there’s support for this first step I’d be happy to start said Chapter 10 and populating it with what I can gather from the existing library code.
OpenSCAD has a weird relationship with libraries.
-
No package manager has ever really gained much adoption
-
There's not a lot of community knowledge on how to make a library
- The language needs additional features to better support libraries. e.g.
Namespaces
There has been much discussion on the future direction of OpenSCAD including
many such features, see here
https://github.com/openscad/openscad/wiki/OpenSCAD-Enhancement-Proposals
& here https://github.com/doug-moen/openscad2/blob/master/README.md for
example, plus much past discussion in the headspace of the development
community. Note that they are proposals and still need design work (IMHO)
and not necessarily fully endorsed direction.
But as Hugo mentions, there is only a small pool of spare-time developers,
the resources available vary, so progress has to go in baby steps. An
unfortunate reality.
It should also be noted that OpenSCAD is young, according to Wikipedia, the
initial release was 19 February 2010. Happy 9th Birthday!! And only really 4
major releases in that time, with the 5th hopefully soon.
Compare to 47 years for C, or 29 for Python, I imaging the early versions
were also clunky.
Admin - email* me if you need anything, or if I've done something stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I suggest that a useful first step might be legitimizing what libraries are currently available by adding them to the OpenSCAD User Manual… as say Chapter 10. That way at least those are aren’t adverse to RTFM would see that libraries are not simply routines of unknown providence showing up on Thingiverse.
If there’s support for this first step I’d be happy to start said Chapter 10 and populating it with what I can gather from the existing library code.
> On Feb 20, 2019, at 2:45 PM, MichaelAtOz <oz.at.michael@gmail.com> wrote:
>
> lostapathy wrote
>> OpenSCAD has a weird relationship with libraries.
>> 1) No package manager has ever really gained much adoption
>>
>> 2) There's not a lot of community knowledge on how to make a library
>
> 3) The language needs additional features to better support libraries. e.g.
> Namespaces
>
> There has been much discussion on the future direction of OpenSCAD including
> many such features, see here
> <https://github.com/openscad/openscad/wiki/OpenSCAD-Enhancement-Proposals>
> & here <https://github.com/doug-moen/openscad2/blob/master/README.md> for
> example, plus much past discussion in the headspace of the development
> community. Note that they are proposals and still need design work (IMHO)
> and not necessarily fully endorsed direction.
>
> But as Hugo mentions, there is only a small pool of spare-time developers,
> the resources available vary, so progress has to go in baby steps. An
> unfortunate reality.
>
> It should also be noted that OpenSCAD is young, according to Wikipedia, the
> initial release was 19 February 2010. Happy 9th Birthday!! And only really 4
> major releases in that time, with the 5th hopefully soon.
>
> Compare to 47 years for C, or 29 for Python, I imaging the early versions
> were also clunky.
>
>
>
> -----
> Admin - email* me if you need anything, or if I've done something stupid...
>
> * click on my MichaelAtOz label, there is a link to email me.
>
> Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
>
> The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
A
adrianv
Thu, Feb 21, 2019 12:19 AM
I suggest that a useful first step might be legitimizing what libraries
are currently available by adding them to the OpenSCAD User Manual… as say
Chapter 10. That way at least those are aren’t adverse to RTFM would see
that libraries are not simply routines of unknown providence showing up on
Thingiverse.
If there’s support for this first step I’d be happy to start said Chapter
10 and populating it with what I can gather from the existing library
code.
This sounds like a great idea. The only question I have---having not
examined the libraries in question---is whether they are good libraries. Is
the API well thought out. I don't want to put up roadblocks to progress,
but you want to get things off to a good start.
--
Sent from: http://forum.openscad.org/
boxcarmib wrote
> I suggest that a useful first step might be legitimizing what libraries
> are currently available by adding them to the OpenSCAD User Manual… as say
> Chapter 10. That way at least those are aren’t adverse to RTFM would see
> that libraries are not simply routines of unknown providence showing up on
> Thingiverse.
> If there’s support for this first step I’d be happy to start said Chapter
> 10 and populating it with what I can gather from the existing library
> code.
This sounds like a great idea. The only question I have---having not
examined the libraries in question---is whether they are good libraries. Is
the API well thought out. I don't want to put up roadblocks to progress,
but you want to get things off to a good start.
--
Sent from: http://forum.openscad.org/
HJ
Hugo Jackson
Thu, Feb 21, 2019 12:34 AM
As per this discussion I’ve been spending the afternoon looking at the existing libraries and I would say they are of mixed quality, so part of the work I’d be willing to undertake would be to refactor most of them, and subject their modification to whatever the general review process is for code enhancements.
There are a number of libraries that really should be folded together… there’s a least 3 “shape” libraries, some of which have overlapping functionally, and some that have modules that just don’t work, not to mention libraries that haven’t been worked on in years so they bring up “assign deprecated” and other similar errors.
I’ve used source control in many forms but not GitHub and I don’t know what the protocol and procedures would be for submitting proposed changes and the release mechanism, so I’d need a little handholding help with that… perhaps there’s some already overworked code developer maintainer who could shoot me an offer to help me get bootstrapped into “how to submit changes to the OpenSCAD master branch”.
I suggest that a useful first step might be legitimizing what libraries
are currently available by adding them to the OpenSCAD User Manual… as say
Chapter 10. That way at least those are aren’t adverse to RTFM would see
that libraries are not simply routines of unknown providence showing up on
Thingiverse.
If there’s support for this first step I’d be happy to start said Chapter
10 and populating it with what I can gather from the existing library
code.
As per this discussion I’ve been spending the afternoon looking at the existing libraries and I would say they are of mixed quality, so part of the work I’d be willing to undertake would be to refactor most of them, and subject their modification to whatever the general review process is for code enhancements.
There are a number of libraries that really should be folded together… there’s a least 3 “shape” libraries, some of which have overlapping functionally, and some that have modules that just don’t work, not to mention libraries that haven’t been worked on in years so they bring up “assign deprecated” and other similar errors.
I’ve used source control in many forms but not GitHub and I don’t know what the protocol and procedures would be for submitting proposed changes and the release mechanism, so I’d need a little handholding help with that… perhaps there’s some already overworked code developer maintainer who could shoot me an offer to help me get bootstrapped into “how to submit changes to the OpenSCAD master branch”.
> On Feb 20, 2019, at 4:19 PM, adrianv <avm4@cornell.edu> wrote:
>
> boxcarmib wrote
>> I suggest that a useful first step might be legitimizing what libraries
>> are currently available by adding them to the OpenSCAD User Manual… as say
>> Chapter 10. That way at least those are aren’t adverse to RTFM would see
>> that libraries are not simply routines of unknown providence showing up on
>> Thingiverse.
>> If there’s support for this first step I’d be happy to start said Chapter
>> 10 and populating it with what I can gather from the existing library
>> code.
>
> This sounds like a great idea. The only question I have---having not
> examined the libraries in question---is whether they are good libraries. Is
> the API well thought out. I don't want to put up roadblocks to progress,
> but you want to get things off to a good start.
>
>
>
>
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org