I totally agree that there's lots of room for improvement.
You give many good points. I'm seeing different ways to
solve some of those but having a solution would be great.

Looking at all the topics, that seems to be more work than
a full time developer could handle in a year. But we need
to start somewhere I guess.

If you'd like to help that would be awesome. For topics
that need code changes in OpenSCAD it can help to discuss
specifics in more detail on the IRC channel but there's
no such thing as an official process.
It's hard to tell in general what can be accepted, but if
you check the github history, there's quite a number of
contributions that were merged lately, notably the generic
tail recursion (https://github.com/openscad/openscad/pull/3020)
which is a very cool addition.

On 14.09.19 16:29, sampo-openscad19@zxid.org wrote:

Why? I don't see anything wrong with features being implemented
as a library. We have the problem that it's not easy to discover
and use libraries but I don't think the solution is to build
everything into the language because of that.

So instead of making the core bigger and bigger, solving the
other issues like library discovery and maybe also adding some
features the help implementing libraries may scale much better.

People already are doing that using libraries, e.g. see
(https://www.thingiverse.com/thing:644830). The only way to
add short names to the core would be to support both long
and short form which is not ideal.

Apart from that, I think that is more a problem of getting
editor improvements. I also work a lot with Java code and
most of the existing code is not exactly known to use short
names. However I rarely ever type those. Modern IDEs generate
almost all of that via code completion or suggestions.

There's a couple of libraries that already do a very good
job of that. However those might need some help. Specifically
BOLTS seems like an awesome effort with focus on standardized
mechanical components (like nuts and bolts). At this point
it looks like it's lacking people who continue working on
it (or care about the OpenSCAD part).

I suspect the only way to do that without globally breaking
all existing designs is to create wrappers that can be
included when desired.

It's in the cheatsheet http://www.openscad.org/cheatsheet/
If it's missing in the manual, it should be added of cause.

Does the "->" imply to change the name instead of adding new
features?

I agree that the menu is not ideal. My suggestion would be
to fix that problem in a more general way though. Right now
there is no way of configuring keyboard shortcuts or the
toolbars. With that feature available, I would assume there's
hardly any need to go into the submenu anymore as I suspect
not many people actually use all of the options. Being able
to put the maybe 2 ones that are used often into the toolbar
and on shortcuts might be even a quicker way to access them.

On a separate note there's always the big issue that MacOS
is totally different regarding shortcuts causing collisions
and headaches all the time. Having that setup configurable
might help solving those issues too.

C-space is the candidate for code completion. However
configurable shortcuts would solve that too.

Already used as shortcut. (Configurable shortcuts! :-)

Depending on what it means in detail, that should be not
very complicated (multiple file formats?).

That one is actually still free I think :).

I don't understand what that means.

Might be a bit tricky as it's currently grabbed by
the editor for font size changes. Not sure how often
that is used though.

All except the transformations sound like a good fit
for one of the libraries (BOSL2?).

As for the transformations, those may need support from
the core, specifically to automatically subdivide the
mesh. Especially for bending there's a longer discussion
on github already. I suspect that's something a number
of people would like to see.
https://github.com/openscad/openscad/issues/815

...
Skipping the rest for as this is already quite long :-)

ciao,
Torsten.

On 2019-09-14 18:57, Torsten Paul wrote:

Interesting 5 year old discussion on github.... as you say and the
comments there point out you need a (re-)meshing capability to produce
uniform mesh to do any sort of useful bending. Also, you need a way to
perform the object vertex transformations. Both of those capabilities
are still missing in OpenSCAD.

You can do both in AngelCAD though - also using an OpeSCAD STL as
starting point
https://gist.github.com/arnholm/af72c7d0790bb3d72e6bdf29c7aac1ed

Carsten Arnholm

On 14.09.19 20:51, Robin2 wrote:

I'm not sure there is a clear answer to that. As far as I
know it was conceived as tool to help with designing RepRap
style 3d printers quite some years ago. So it started out as
an ad-hoc tool, not a designed language - that still shows
and probably always will be part of it.

It's not a commercial product so there's not some kind of
official target audience.

It's used for very interesting and fun things, including
education, math or even generating punching cards for knitting
machines
https://mathgrrl.com/hacktastic/2019/05/punch-card-knitting-machine-patterns-with-openscad/
One area where I'd like to see it improving is accessibility.
OpenSCAD is already used in some 3d printing workshops:
https://www.nypl.org/about/locations/heiskell/dimensions

For designing things in industry applications, I would assume
that's the case. I personally don't see OpenSCAD competing in
that space anytime soon (or more likely that will never
happen, and that's fine).

However a professional designer might still decide using it
for smaller designs that can be easily shared and modified
by anyone without the need to buy expensive software available
only on Windows or signing in to cloud services imposing
random additional restrictions.

That said, there are examples of impressively huge projects
created with OpenSCAD (https://www.openscad.org/gallery.html).

Yes, I totally agree with that.

ciao,
Torsten.

My two cents

Disagree; it would break 99.99% of past code.

Possibly, but how do you control its scope, libraries written one way or the other for example.

It's a wiki, change it.

Try the snapshots, there is auto-complete, e.g. type 'tr(' -> 'translate('.
At times I agree about lots of typing, I have carpel tunnel and epicondylitis,
height= instead of h= in linear_extrude for example, let alone linear_extrude...
Sometimes I write my own abbreviations, you can quite easily do e.g.
module T(v) translate(v) children();
However, one of the things I like about OpenSCAD is its simplicity and easy of learning.
Using whole meaningful words means not having to remember what abbreviation or acronym to use.
If this was introduced you would need to support both, contaminating the language.

https://github.com/openscad/openscad/issues/649
That is also a good example of different peoples work flow, and how little things can impact
different approaches.

Agree a shortcut is needed, personally I'd suggest Ctrl-=
Also View/Center need one, perhaps Ctrl/Shft-= ??

Note, keys documented here https://github.com/openscad/openscad/wiki/Keyboard-Shortcuts
May be slightly out of date. It shows the Mac related peculiarities.

I agree with tp re customisable key layout, but some should be locked, e.g. F5/F6 as they have
become part of the language.

F7 too easy?? [added in 2019.05]

Not following you.

C-Shift-P?? (as I is taken)

Not following you.

As mentioned, these are in the editor. Perhaps they could be freed-up if zoom icon(s) were
introduced?

I actually think this would be good (tube, not wall=) purely because it would be the most used
shape.

Here you start getting issues, square tube in shops varies widely around the world, including
radius of corners. Same goes for profiles. That shouts 'library' to me.

I don't support this, with wall= it is no longer a cube or a cylinder.
Do you go further, define thickness for various walls and or have or not some end caps etc?
You'd be turning one tool into a swiss army knife, when you just want to butter bread.

No. That is a slicers job.

Yes please. Animatable.

As the geometry is not calculated in preview, I suspect this can't be done.

As the geometry is not calculated in preview, I suspect this can't be done.

Complicated, as no doubt you want differences such as per face grain etc.

This email has been checked for viruses by AVG.
https://www.avg.com

On 2019-09-14 19:59, Torsten Paul wrote:

Of course I was referring to the explicit request for bend()
functionality as available to the end user, I am sure you understood
that. It is certainly not "wrong" that those capabilities are missing,
otherwise they would not be requested as the TS did.

Indeed, it was the case 5 years ago and today.

You probably guess that, but MY point was that bending/morphing is
possible if you want to do it. AngelCAD came to be after I started using
OpenSCAD in 2015 and suggested various improvements then, but it was met
with too much "cannot do" so I solved it in a different way.

Carsten Arnholm

On Sat, Sep 14, 2019, at 4:57 PM, Torsten Paul wrote:

If you want core support for arbitrary non-affine transformations such as "bend", then in general it is more complicated than just the need to automatically subdivide the mesh. Non-affine transformations can also cause self-intersections, and can cause triangles to collapse. That damage needs to be repaired before you can feed the output into CGAL operations such as intersection and union.

In the case of Bend, you get self-intersection just by bending a pipe past 180°.

I was one of the people discussing how to do non-affine, plastic deformations in OpenSCAD back in 2014. To do this in mesh space, we discussed automatic subdivision in regions where space expands, and remeshing to a valid mesh afterwards. It seemed way too complicated to actually implement (for me, at least). Since I needed this feature for my own projects, I implemented it outside of OpenSCAD by representing shapes using signed distance fields (SDF). Using that representation, you can represent curved shapes exactly. Plastic deformations like twist and bend are easy to implement, and they output an exact representation, so there is no loss of information or degradation of the model if you apply a sequence of non-affine transformations. Then, as a final step for generating an STL file, you convert the signed distance field into a mesh using available open source software.

There was discussion, some time around 2014, about adding native support for working with SDF representation to OpenSCAD, but it's a big and radical change, and seems unlikely to happen.

On 15.09.19 05:20, OzAtMichael wrote:

It's a bit tricky as a naive implementation would at least
cause issues with the camera location (same as when using
a huge cube manually), but it should be doable.

There's a partially working but unfortunately abandoned
implementation at
https://github.com/openscad/openscad/pull/1424

ciao,
Torsten.

On 9/14/2019 7:29 AM, sampo-openscad19@zxid.org wrote:

No, there's really no reason.  It would be much better to have
well-known libraries distributed with the program.  Primitives should be
added only for those things that have to be primitive.

There's a decent argument that even translate, rotate, scale, cylinder,
cube, and the ilk should be library modules on top of multmatrix and
linear_extrude.

Strongly disagree.  Readability is critical.  Terseness is bad.

If we were starting from nothing, maybe.  But now it would be too
disruptive and confusing.

Shrug.  I almost never have to get into the menus, so there must not be
too much there that I need.

I find the mouse wheel to be a very natural zoom control.

Sound like decent library fodder, though I have to wonder how much use
they would really get.

These are obscure enough that they should not use up single-letter
module names - and especially not as primitives, where they would
collide with every user's usage.

Perhaps, though it would be easy enough (except for hull) to create
library modules hollow_cube() et al.

It's pretty easy to do a set of linked cylinders, and that should
perhaps be a library module.  I haven't thought about making it into a tube.

A library function to produce a list of Bezier points would be good, and
then you could use that as input to your linked-cylinder module.  (And I
have!)

I thought about this a bit once and the rotation of the square defeated
me.  I don't remember the details, but it wasn't obvious how the square
would be rotated as you connected one point to the next.

What does that mean?

I don't know enough math to discuss bending.

What is stretching that isn't handled by scale( )?

Shear isn't too hard to put on top of multmatrix, and I don't know (and
haven't thought too much) if it's possible to come up with a general
shear that's less complex than multmatrix.  There's a lot of different
shear combinations.

That would be cool, but is clearly just (difficult) library work.

There are screw/bolt libraries.  It's mostly a matter of making them
easy to get.

What does this mean?

I think you can do this with linear_extrude today (and hence you could
make your own module), but it seems reasonable.

JordanBrown wrote

That should be the test for every change.

...R

--
Sent from: http://forum.openscad.org/

sampo-openscad19 wrote

Would be nice as external libraries, but not the core language.

sampo-openscad19 wrote

Strongly disagree. It's almost never useful with center=true for anything
but spheres. Would break backwards compatibility.

sampo-openscad19 wrote

Need quite a few more decimals than that to be useful.

sampo-openscad19 wrote

Disagree. Keep the language as close to spoken language as possible. It's
easy to make yout own T() if you want (I almost do, I have my xtran(),
ytran() and ztran() to make it clearer when I only move in one direction,
and corresponding xrot() et cetera). Would break backwards compatibility.

sampo-openscad19 wrote

Disagree. That's not how it's done in other programs, and would give menu
clutter.

sampo-openscad19 wrote

Not something I'd use, but I can see that it's useful. Agree.

sampo-openscad19 wrote

Agree that export should be able to be done in batch. Disagree that STL is
the most important export, at least not for me. I don't 3D-print, I have a
laser cutter, so SVG is the format for me.

sampo-openscad19 wrote

Wouldn't use the keybord shortcut, I seldom remember more than the most
common. I'm pretty sure there is a command line option for it, I'm pretty
sure that I batch it.

sampo-openscad19 wrote

Wouldn't use, scroll wheel is more convenient. Don't see any harm in it,
though.

sampo-openscad19 wrote

I already have made versions of those. Shouldn't be included in main
language, but would be suitable for an external lib.

sampo-openscad19 wrote

Shouldn't be included in main language, but would be suitable for an
external lib.

sampo-openscad19 wrote

Shouldn't be included in main language, but would be suitable for an
external lib.

sampo-openscad19 wrote

Yes, these would be useful, though I'd probably make it a path_extrude().

sampo-openscad19 wrote

Shouldn't be included in main language, but would be suitable for an
external lib.

sampo-openscad19 wrote

Shouldn't be included in main language, but would be suitable for an
external lib.

sampo-openscad19 wrote

Would be nice, sometimes it can be hard to see when you have complex models.
I usually have to revert to using intersection() to remove part of the
object for view.

sampo-openscad19 wrote

Shouldn't be included in main language, but would be suitable for an
external lib.

sampo-openscad19 wrote

Textures is a bit of overkill, imho, but I would like to be able to render
in color.

--
Sent from: http://forum.openscad.org/

As some people know, I created my own OpenSCAD-like language, Curv. Some of the changes I made align with what Sampo is asking for, so I'll comment on those specific issues, based on several years experience using Curv.

On Sat, Sep 14, 2019, at 10:29 AM, sampo-openscad19@zxid.org wrote:

Curv works this way: all primitive shapes are centred on the origin. It has proven to be very convenient. My entire shape library is designed around the idea that primitives are centred, so that everything composes nicely with a minimum of extra translations.

Backward compatibility is paramount in OpenSCAD. For people who want centred primitives, there should be a user-provided library that redefines the primitives to be centred.

OpenSCAD should add the flexibility to override built-in modules with new modules of the same name. You should be able to define a module called cube, and you should be able to reference the builtin module cube while defining the new version of cube.

My abbreviation for translate is move. This should be done in a library, because it's a personal preference. Ditto for many of Sampo's other suggestions.

C-space is globally reserved in some desktop environments. MacOS uses Cmd-Space for Spotlight search. Some Linux and Windows systems use Ctrl-Space to switch input editors.

How about C-Home? Or maybe a configuration file for user defined key bindings?

Curv has two non-affine transformations, bend and twist, that I use a lot. Can't live without them. These should be implemented in OpenSCAD in a user-supplied library.

OpenSCAD should provide the ability to access the mesh geometry of a shape from user code. Then bend() could be implemented using the approach that Carsten described, in his AngelCAD implementation.

Whenever this feature request is discussed, it is always dismissed by claiming that it is incompatible with preview. That's not true. OpenSCAD has a number of built-in modules that access the mesh geometry at preview time: render(), resize(), minkowski(), hull(). Yes, it's true that these operations can slow down preview. With complex models, render() can also speed up preview, or fix rendering problems in preview. If I can call render() from a user-defined module, then why is it so objectionable to allow me to call a variant of render() that returns the mesh as a list?

The cylinder()  primitive is the standard way to construct pyramids in OpenSCAD. Try this:
cylinder(h=10, r1=10, r2=0, $fn=4);
No doubt there are already libraries in existence that provide this same capability using a pyramid module.

You can do this interactively using the previewer. Define a slider for moving the boundary of the big cube and enable "automatic preview". There are lots of interactive visualization tools you can build once you have a previewer. They don't all need to be built in.

My complaint against the OpenSCAD previewer is that automatic preview is laggy. Curv has a much more responsive previewer, and it makes a big difference in terms of quality of experience, so I think this issue should be considered.

Curv compiles programs with previewer annotations into a specialized form that supports responsive animation (60 FPS) when you move a slider. The tradeoff is restrictions on what programs can be compiled in this way. Over time, I'm progressively eliminating  these restrictions. So I prioritized responsiveness over generality.

Curv supports full colour models and full colour 3D printing. My Prusa doesn't support this, but there online 3D printing service providers that support this, and I really enjoy being able to make full colour prints. My new favourite colour 3D printing tech is the HP 3D Jet Fusion 500/300. It prints full colour nylon, which is tough and strong, more durable and somewhat brighter colours than "full colour sandstone" from a Zcorp printer, and a lot cheaper than Shapeway's Stratasys J750.

In Curv, you can attach a colour function to a shape. A colour function maps [x,y,z] coordinates to colour values. So every "voxel" in a shape can have a different colour. This was easy to implement, and it's really cool. "Wood grain" might sound out-of-scope for OpenSCAD, but once you support 3D colour functions, it's quite possible. One of my users surprised me by demoing a wood grain model in Curv: I hadn't previously considered this to be something I can do. But now I'm a convert. I think this would be a popular feature for OpenSCAD to adopt.

The general theme of my recommendations is to give users lots of power to define things in code, rather than hard coding a lot of features in C++. I think this is already a reason why OpenSCAD is attractive, so we should just keep building on this core strength.

Doug Moen.

able to reference the builtin module cube while defining the new version
of cube.

It doesn't make for readable and reusable code if everybody has their own
dialect of OpenSCAD where cube does something different.

objectionable to allow me to call a variant of render() that returns the
mesh as a list?

I think because a list is an expression and all expressions are
evaluated in OpenSCAD before any geometry is created.

On Mon, 16 Sep 2019 at 16:22, Doug Moen doug@moens.org wrote:

On 9/16/2019 12:56 AM, Robin2 wrote:

Yes, though the standards are different for different "levels".

Primitive - should probably be only those things that must be
primitive, or that have significant performance gains from being primitive.

"Standard" library distributed with program - common usage.

"Extra" library distributed with program - some specialty stuff, but
might be used by only 10% of users.  Or maybe even fewer.

Or maybe there are a few "extra" libraries for specialties - e.g.,
construction materials, fasteners, et cetera.

And then there's everything else, that's not distributed with the
program - yeah, whatever. :-)

doug.moen wrote

Why?

How many users, and what type of user, would benefit?

...R

--
Sent from: http://forum.openscad.org/

On 16.09.19 11:54, Troberg wrote:

Just to clarify, the built-in PI is not just 3.14,
it's using the platform C/C++ definition M_PI which
should be double precision.

ciao,
Torsten.

Robin2 wrote

I agree wholeheartedly. I have no trouble remembering shorthand substitutes
for commonly used keywords, but ONLY if I defined them myself. As you say,
single character shortcuts are not only bad for searching, but also for
parsing, should one want to generate a translation program that will take an
OpenSCAD file with shortcuts and pretty-print the full OpenSCAD code. I love
the idea of xtran(n), ytran(n), ztran(n), and so on.

This discussion has been a real eye-opener for me.  I will definitely be
generating a library file that includes many of the ideas presented here...
shortcuts, tubes, hollow cubes, and so on, and will attempt to write a
program that will translate all the shortcuts at the very least, back to
native OpenSCAD.

--
Sent from: http://forum.openscad.org/

I have a tube in my library but I can't think a use for a hollow cube. Any
boxes I make have rounded corners and an open face.

On Mon, 16 Sep 2019 at 23:49, lar3ry lar3ry@sasktel.net wrote:

sampo-openscad19 wrote

As with others I agree this is a terrible idea for the same reasons.  But
some abbreviations can be handy.  BOSL provides a bunch of shortcuts like
this.

One thing that I find really puzzling is the opposition to standardization
that I see.  One poster said abbreviations are only ok if he made them up
himself.  I mean, yeah, I understand it might be a little more work---maybe
it takes a week---to get used to someone else's abbreviations.  I have a
hard time understanding how people wouldn't learn them from regular use.
(If it's so hard...how did they learn to use the native OpenSCAD commands in
the first place?)  It's really beneficial to have a more unified set of
extensions rather than everybody makes up their own abbreviations.  It means
posted code examples are more comprehensible, for example.  In general it
makes code more sharable.

One person suggested that we need to understand who the users are.  If the
users are indeed people with only a passing interest in modeling who want to
make 3 throw-away models per year, then there's no reason to do any further
development.  Why bother?

Maybe my frustration with the limits of OpenSCAD as it stands stem from
being a user with a deeper interest in real modeling.  Should I be using
some other tool?

Based on what I've seen I can say that (1) features you program are
extremely unlikely to be integrated into OpenSCAD in any official way and
(2) you would almost certainly be reinventing the wheel.  Almost everything
you suggest that can be done in libraries has already been done by somebody.
The BOSL and BOSL2 libraries support almost everything you propose.  (Note
BOSL is the old, stable library and BOSL2 is new, but currently unstable
version in development.)

See here for documentation:  https://github.com/revarbat/BOSL2/wiki  Most
of what you asked for is in shapes or transformations.  I would suggest
that you might take a look at BOSL2 and other libraries and see what
features are lacking from them before you start work on your own extensions.

On the matter of redefining primitives like cube(), it is already possible
to do this.  You just can't ever use the old cube() afterwards.  If you
really want to prevent users from making their own nonstandard versions
where cube() makes a sphere or something, you would need to ban redefinition
of primitives.  Allowing users to call the original cube() and know for sure
it's the original cube() should make things less confusing, not more so.

--
Sent from: http://forum.openscad.org/

nophead wrote

I was thinking of something that floats, but in retrospect, I guess the
slicer will take care of making it hollow.

--
Sent from: http://forum.openscad.org/

Non-FDM printers frequently want hollow shapes, with escape holes, to save on raw materials.

This email has been checked for viruses by AVG.
https://www.avg.com

On Mon, Sep 16, 2019 at 11:20:57AM -0400, Doug Moen wrote:

This isn't too difficult to implement, I'd think.
Just rename the current cube () primitive to __cube () and provide
a default module cube () definition that calls __cube()...

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

That doesn't work because the definition of cube overrides the original so
that __cube() calls the new one and creates recursion.

On Tue, 17 Sep 2019 at 11:03, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:

What I meant was that the language can facilitate this option by
renaming the cube primitive to __cube(), and then having an
overridable module in place for the backwards compatiblity.

Now, the primitive may be able to do a few things that normal modules
cannot. For example, while it is easy to provide a centered=false
default on the module, you can just allways pass on centered=centered
on to the primitive. The "default" on the parameter will take care of
when the parameter is not specified. On the other hand I don't know
how to make the r=xx, d=yy behaviour on a cylinder. Does the primitive
"cheat" and do things that a user-written module cannot? Or are my
openscad skills simply not good enough. I don't know.

In any case, I was not suggesting that you could do this already by
redefining the prmiitve from your user-file.

Roger. 

On Tue, Sep 17, 2019 at 11:52:50AM +0100, nop head wrote:

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

Sorry, yes that would work.

Currently it is fairly easy to override the geometric primitives with
something that produces the equivalent polyhedron or polygon without
calling the original. I do that myself for sphere() to make one that
includes the poles and equator.

To handle the multiple parameters I default the alternatives to undef and
then use is_undef(), so I think one can do the same as the original but it
would be quite a lot of code to do that and also check for errors, so speed
might suffer.

module sphere(r = 1, d = undef) {                  //! Override
sphere so that has vertices on all three axes. Has the advantage
of giving correct dimensions when hulled
R = is_undef(d) ? r : d / 2;
rotate_extrude($fn = r2sides4n(R))
rotate(-90)
semi_circle(R);
}

On Tue, 17 Sep 2019 at 12:10, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:

rew wrote

Sorry, but I just can't see the point. What is so sacrosanct about the name
"cube" that someone can't work with a derived module called (say) "myCube"
without any need for developers to waste time changing the underlying code.

I get the impression that there is a large number of libraries with,
perhaps, a lot of close-but-not-perfect duplication amongst them. If that is
the problem then it should be fixed by some process of getting library
developers to work to a common standard, not by changing the core code.

...R

--
Sent from: http://forum.openscad.org/

Amen.  The problem isn't that we need to extend the language, it's that
we need to make library re-use (and subsequent improvement) productive
like most every other language.

We would almost certainly converge on a certain set of really good
libraries as a standard.  But trying to design them by committee into
the language is how you get things like the Java versions of 20 years ago.

On 9/17/19 7:34 AM, Robin2 wrote:

I like the idea of this. Can you tell us the definition of the function: $fn
= r2sides4n(R))

--
Sent from: http://forum.openscad.org/

Yes it is here:
https://github.com/nophead/NopSCADlib/blob/master/utils/core/global.scad#L37

On Tue, 17 Sep 2019 at 15:22, lar3ry lar3ry@sasktel.net wrote:

Robin2 wrote

It seems to me that the main use of redefining modules is to extend
functionality somehow in a library, so the existing built-ins can behave
consistently in the context of the library with other functionality.

The argument that the name "cube" is sacrosanct appears every day on this
forum:  many people seem to think that the burden of learning a new command
is quite overwhelming.

I would say that the situation is not so clear.  There do not appears to be
very many good libraries, well documented, that you can easily find.  I'm
not aware of a lot of good libraries that duplicate each other
substantially---maybe just BOSL with parts of dotSCAD.  But in my efforts
to hunt for libraries I saw a lot of functionality duplicated many times by
different people, maybe not put out as a library, but code that does the
same class of basic things, written by each individual to support other
purposes, because sharing libraries seems to be, for some reason, a very
difficult thing.  And if you write a library for your own use there's little
reason to bother documenting it.

The lack of a really clear mechanism for distributing libraries has been one
problem.  It's pretty hard to find the various libraries that are scattered
on Thingiverse.  The general hostility of people on the forum to the use of
libraries is another factor that I think has discouraged the development of
a functional approach to libraries.

--
Sent from: http://forum.openscad.org/

quite overwhelming.

OpenScad is a tiny language and can be learned in its entirety in about a
day, which I did many years ago. Libraries are much larger things to learn,
and if I can write everything I use myself, why would I spend time learning
somebody else's library?

I think the reason why they don't gain the same traction as conventional
programming languages is most things are very easy to do in OpenSCAD with a
few lines of code, whereas most libraries for other languages are a lot
bigger and more complicated.

On Wed, 18 Sep 2019 at 00:06, adrianv avm4@cornell.edu wrote:

My original reason for wanting this feature is the Relativity library.
https://github.com/davidson16807/relativity.scad

Relativity extends the standard primitives cube, sphere, etc, with upward compatible new features: a system of property inheritance inspired by CSS.

But, because of the way OpenSCAD works, Relativity needs to invent new names for all of the primitives. So, cube becomes box, cylinder becomes rod, and so on.

So if you want to use Relativity in an existing project, you need to rewrite your code to replace cube with box and so on.

It would be better if Relativity could just add new features to cube, sphere and so on without requiring you to rewrite all of your code.

This would not be a problem in any modern programming language, because all modern languages support name spaces.

The underlying goal of many of the suggestions in my email was to provide tools for library writers, so that libraries can work better. And so that libraries can do things that currently require a change to the C++ core. We need a better library ecosystem. If you don't use libraries, then many of my suggested language changes won't help you.

Doug Moen.

On Tue, Sep 17, 2019, at 7:11 PM, adrianv wrote:

But you can redefine cube and sphere. They hide the originals but there
really isn't any need to call the originals as they don't do anything
special. You would have a problem redefining polygon, and polyhedron though
I think.

On Wed, 18 Sep 2019 at 00:46, Doug Moen doug@moens.org wrote:

On 9/17/19 6:28 PM, nop head wrote:

I wish we would quit repeating this like it's the whole truth.  This
type of talk derails discussions that might lead to a decent library
ecosystem.

Yes, it's "easy" to do many things quickly.  It's also very easy to end
up with a "library" that's not actually very reusable, or hopelessly
slow, or fails to handle edge cases, or fails to provide reasonable
validation/assertions (making it easy to have problems using it).

Making good, reusable, documented libraries is hard.  Both because of
the nature of the work, but also because there are very few great
examples of libraries for OpenSCAD.  There's little work to borrow from,
so users tend to fall into the same beginner traps and either call it
"good enough for today's project" or give up on OpenSCAD entirely.

I have talked to many people off-list who were discouraged by this
"OpenSCAD doesn't need libraries" talk and just gave up rather than
contributing.  I really wish the negativity around libraries and package
managers would stop.

nophead wrote

I did not find it so easy to learn OpenSCAD as apparently you did.  Dealing
with the immutability of variables, and the need to use tail recursions
instead of loops---these things are not obvious.  And without any code
examples (because there are no libraries to read) one is left rather adrift
in trying to figure this stuff out.

Did you not just recently post that you redesigned your code using a
different design philosophy of making everything from extruded 2d shapes and
got it to render much faster?  (Assuming I remembered that correctly) that
suggests to me that you are still learning how to use OpenSCAD.  Note that
knowing how to use the language is not just knowing its commands, but
understanding fully, deeply, how they interact, and the advantages and
disadvantages of different approaches for modeling the same thing.  I'm kind
of skeptical that there are many people who really understand the ins and
outs of polyhedron() within the first day of using OpenSCAD.  Indeed, there
may not be many such people at all.

The question "If I can write everything I use myself, why would Is spend
time learning somebody else's library?" is really bizarre to me.  I can, in
principle, write everything I do on the computer myself in assembly
language.  But would I want to do that?  Heck no!  It would take a lot
longer to do that than to learn the libraries.  And at least for me, the
effort of learning a library, or the 10 seconds it takes to check the
library manual to remember a parameter name, is much less than the effort
required to write the thing again from scratch.  And for me it tends to
produce code that is more maintainable.
Indeed, the question I would pose in general is: "If there is a library that
does it, why would I spend the time writing it myself??"

I think the reason they don't gain the same traction as conventional
programming languages is that a vocal population here on the forum thinks
they are unnecessary because the things thosepeoplewanttodo are easy.
And for some reason some of these people vocallyoppose* libraries instead
of just ignoring them.  That's what I find puzzling.  If someone is happy
with base OpenSCAD that person can be happy and go model something----and
ignore any libraries that are written.  Why are libraries so offensive to
people who aren't going to use them?

If you want to make just rectangular objects with sharp corners, then things
are in fact pretty easy.  But if you want to do things that are curved, with
rounded edges, not so much.  My first OpenSCAD design is 108 lines and my
second one is the same length.  My third one design is 357 lines of
OpenSCAD, and it wasan't "very easy" or what I would consider "a few lines
of code".  The modeling process was pretty painful and there were lots of
steps that were trial-and-error based, which I hate.  It also takes about 20
minutes to render, which was pretty annoying during design.  The desire to
make this sort of model easier is what lead me to search for libraries.

--
Sent from: http://forum.openscad.org/

On 9/17/19 7:21 PM, adrianv wrote:

This times 1000!  Nobody is going to make you use other people's
libraries, but there's no reason to discourage everyone else from
writing them. Please quit doing so!

adrianv wrote

It is also that the language needs further mechanisms to facilitate
libraries.
There is a basic mechanism, the libraries directory of OpenSCAD releases,
however as MCAD has shown it's development is hindered by (as Doug has
written just now) lack of " tools for library writers, so that libraries can
work better".
Then there can be a concept of 'std' libraries and external libraries. Once
there is better library support a 'std' library will be maintainable and
'best' practice can be developed. [I think tp's 'Functions literals / higher
order functions' will prove to be very helpful, add namespaces and probably
few other smaller pieces to support versioning, and it becomes workable]

There are, at least, two types of people here, those who subscribe to the
concept of standard libraries, and those who prefer to roll their own.
Personally I'm in both camps. Both types have explained their reasoning
here.
I have not detected hostility, and I don't think views of roll their own are
trying to discourage developments. Or that evangelicals should expect others
to see the light.

This type of discussion come up every year or two then fades away.

Instead of discussing libraries, I think the focus should be on "tools for
library writers" AND maintainers.
Then in conjunction developing 'best' practice guidelines on the criteria
code should have to be considered for formal inclusion in both a core
standard library [distributed in a release], or a 'recognised' external
library [that gets promoted on OpenSCAD web site, support with issues etc].

That's at least 3 phases and won't happen overnight.
I think namespaces would be a next logical step.

[I see there is now a bunch of replies I have yet to read, so obviously not
covered above]

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/

On 9/17/2019 5:51 PM, MichaelAtOz wrote:

Right.  I think it's all "well, OK, but why bother?".

My big project is a 1:25.4 scale model of my house.  It's about 7500
lines, mostly in modeling the furniture.  I just walked through the
"library" files, the files that have functionality that I thought was
sort of common.  Much of that was "common" to my particular problems -
like defining a generic cabinet with drawers.  I tallied maybe 300 lines
that I thought would be of sort-of-general use.

In skimming through BOSL, at a guess it would replace half of those. 
(And, notably, not the single most difficult trig problem - finding
parameters of a segment of a circle given other parameters.)  It would
have given me the Bezier functions that I had to steal from somewhere else.

So, BOSL would give me at best a 2-5% reduction in the number of lines
I had to write.  That's better than zero, but it's not exactly
life-changing.

Maybe (but only maybe) some of my modeling would have been easier if it
had been cast in terms of, say, its path manipulation, but that would
have then required learning how and when to use that feature to achieve
a particular goal.

lostapathy wrote

I have no objection to that approach.

But what I do object to are demands for changes to the Openscad core that
are unlikely to be useful for more than a handful of users.

If something can be achieved with a module built on the existing Openscad
core then I can't see any reason to include that capability in the core.

I don't see the library "problem" being resolved without some leadership
(and I am not volunteering, I don't know enough about it). Someone (or some
small group) needs to pick one or more libraries and make them the primary
libraries. Then a case could be made that other libraries should be
compatible. I don't think this is a simple process.

I am more familiar with the Arduino system. It includes a group of basic
libraries - each with very limited functionality. However some of them are
very far from "best in class". Then there are hundreds of 3rd party
libraries most with almost no documentation apart from the source code. And
the two that I am familiar with that do have extensive documentation have
some substantial gaps in the documentation.

I suspect where the Arduino system differs is that some of its libraries are
very widely used and have become de-facto standards because of that. I get
the impression that none of the Openscad libraries has floated to the top of
the charts in the same way, perhaps because the scope of Openscad usage is
much broader.

Maybe there is also a sense in which some of the Openscad libraries set out
to be "swiss army knives" whereas the Arduino libraries are more focused.

...R

--
Sent from: http://forum.openscad.org/

I think the difference is Arduino libraries and most other software
libraries are just libraries that add some specific functionality but
OpenSCAD libraries like Relativity and BOSL are actually frameworks that
totally change the way objects are coded. They change the look of the code
entirely so it starts to look like a different language.

I have no objection to people writing libraries. I just try to explain why
they don't gain traction like they do for other languages. I use Python
libraries all the time but I just add an import and use some functions. It
doesn't change the way I code the rest of the project. Even adding
something a big as a Web server with Flask doesn't change the basic
language or how I code the rest of the project. And Python's super flexible
import mechanism avoids any name clashes and the package manager pip makes
them trivial to include. OpenSCAD would need those two facilities to make
libraries practical.

On Wed, 18 Sep 2019 at 09:24, Robin2 robin@nbleopard.com wrote:

I wonder if there would be any value in creating and maintaining a central
list of the most widely used OpenSCAD modules/libraries.

Perhaps we could ask people in this forum to submit their top 10, and I
suspect we would rapidly discover a 'core' set of modules which cross over
multiple people, and a long tail of modules used by multiple people, but
nowhere near universal.  There would likely be a lot of redundancy, and
little standardisation between them - but we could at least take an overview
and see whether strong patterns emerge.

and work out  a minimum standard for compatibility, which could then be
published and module/library owners can decide whether to bother to adapt
their code to meet it.

...or has someone already done all this?

Alex Gibson

admg consulting

edumaker limited

. Project management
. Operations & Process improvement
. 3D Printing

-----Original Message-----
From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of
Robin2
Sent: 18 September 2019 09:30
To: discuss@lists.openscad.org
Subject: Re: [OpenSCAD] Extending OpenSCAD from assembler to C or Perlish
language and adding standard library

lostapathy wrote

I have no objection to that approach.

But what I do object to are demands for changes to the Openscad core that
are unlikely to be useful for more than a handful of users.

If something can be achieved with a module built on the existing Openscad
core then I can't see any reason to include that capability in the core.

I don't see the library "problem" being resolved without some leadership
(and I am not volunteering, I don't know enough about it). Someone (or some
small group) needs to pick one or more libraries and make them the primary
libraries. Then a case could be made that other libraries should be
compatible. I don't think this is a simple process.

I am more familiar with the Arduino system. It includes a group of basic
libraries - each with very limited functionality. However some of them are
very far from "best in class". Then there are hundreds of 3rd party
libraries most with almost no documentation apart from the source code. And
the two that I am familiar with that do have extensive documentation have
some substantial gaps in the documentation.

I suspect where the Arduino system differs is that some of its libraries are
very widely used and have become de-facto standards because of that. I get
the impression that none of the Openscad libraries has floated to the top of
the charts in the same way, perhaps because the scope of Openscad usage is
much broader.

Maybe there is also a sense in which some of the Openscad libraries set out
to be "swiss army knives" whereas the Arduino libraries are more focused.

...R

--
Sent from: http://forum.openscad.org/

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

On Tue, 17 Sep 2019 19:12:52 -0500
Joe Francis joe@lostapathy.com wrote:

Thank you for saying this. Writing libraries is not easy. Writing
(re)usable libraries is very hard. I have written and maintained code
in various languages for decades. For every good library I've seen
there have been several that are more trouble than they are worth.

Programmers generalize too soon (hey I did this once, maybe it would
make a good library). They don't think about re-use (this makes my one
case easier, but will be a bear to use for anything else). They don't
document (it's obvious, really). Add to that, the fact that naming is
hard.

This should not prevent the writing of libraries, but it does mean that
it requires more work than some seem to think.

There's also the tension between big "do everything" libraries that
take more time to learn than to use and small, easy-to-learn libraries
that don't do enough.

When someone manages to build a library that gets enough of this right,
it will catch on. We need to keep experimenting to get there.

G. Wade

--
90% of coding is debugging. The other 10% is writing bugs.
-- Bram Cohen

90% of coding is debugging. The other 10% is writing bugs.
-- Bram Cohen

With the current error/warning messages and the echo() in functions
abilities, it has been less painful to debug OpenSCAD codes. But it is not
an easy task  anyway. One of the problems I see with current libraries, and
BSOL is not an exception, is the lack of argument value checks and
error/warning messages. Presumably the functions and modules in libraries
take care of some corner cases but they usually assume the input arguments
are consistent ( a list of vectors is in fact a list of vectors). If by
mistake I code a 2D point in a list of 3D points as an input vector of a
library function I will get an error somewhere. If the error occurs inside
a library function either I stop my work to understand what it does or I
changed it introducing echos to trace the error. This is far from easy and
probably I will discard the library altogether.

Besides good documentation, clever written libraries functions/modules
should include parameter checking and user friendly error/warning messages.
Asserts are mandatory.

Ronaldo wrote

I agree.  I always try to do this, but it's frustrating how hard this is to
do.  I have put in error checks and discovered that my code executes
non-sequentially and produces a cryptic OpenSCAD error before it hits my
assertion.  I'm not sure what I can do in situations like this.  I backed
out an error handling framework I was implementing for a pair of my modules
because it just didn't work.  Is there some way to force an assertion to
run first?

--
Sent from: http://forum.openscad.org/

adrianv wrote

I know that it's possible to use Openscad as a general programming language

• but does it make sense to do so?

To my mind it is an extremely useful product that can create files for 3D
representations of objects from some simple instructions such as cube() and
cylinder()

However my inclination is to use a "regular" programming language (such as
Python) to do anything complicated.  Python (or your languiage of choice)
can write the Openscad code that works using the core Openscad capabilities.
That means that the "Python" coder is freed from the complex maths needed to
create 3D files that can be interpreted by Slic3r and such like without
being restricted by the peculiarities of the Openscad interpreter.

Input data checks and exception handling are well catered for in regular
programming languages and the programmer has complete control over the order
of doing things.

...R

--
Sent from: http://forum.openscad.org/