Not sure what you are trying to convey.

If you do not know what your scripts do and what functions it uses, you
are surely going to have trouble when the underlying software changes.

If the Release Notes do not describe how the current behavior differs
from previous behavior, you probably have other issues with your choice
of tools.

As the maker community starts to move to parametric CAD (in the same way
that traditional product engineers moved from 2D to 3D to parametric
CAD) the pressure on products like OpenSCAD to become better will increase.
The list of surviving products will also shorten.

As a new user, I have no way to know how dedicated this community is to
this project.

If it is run as a toy or vanity project, it will get swept aside as the
market coalesces around projects with a following that are getting
better at a notable pace.

That is just software reality. I am old enough to be able to name a lot
of really good products that just disappeared in spite of the initial
user base. Have you used your Netscape browser lately,  Is your AOL
account very busy, how do you like your Blackberry?
I can go on back through the 90s, 80's and 70s to identify topnotch
products that got overwhelmed when they stopped investing in the future
and lot market share.

Ron

On 2020-04-06 9:42 p.m., adrianv wrote:

--
Ron Wheeler
Artifact Software
438-345-3369
rwheeler@artifact-software.com

On 4/6/2020 6:00 PM, Doug Moen wrote:

OK, thanks.  It also wouldn't work well for different kinds of
materials, which is a color-like property.  (E.g. the water-soluble
stuff for support structures that I would know the name of if I had a
two-extruder printer.)

But that scheme would play fine with the existing OpenSCAD color
behavior, I think.

Are there color-capable tool chains that work in terms of volumes, so
that you can control the interior?  What are the odds that we would ever
want OpenSCAD to integrate into them?

colouring works, then all this existing code will break. I don't think we
want to do that.

I don't think much if anything of mine will break because, as I said
before, I don't expose naked 3D differences and intersections. I always
render and then colour them, so I don't make use of the face colouring that
difference does. If I want a coloured face I union a thin sliver. So all my
volumes are the same colour throughout.

My STL files are rendered with colour in the preview but when the STL is
generated I don't apply any colour because it currently has no effect.

On Tue, 7 Apr 2020 at 06:19, Jordan Brown openscad@jordan.maileater.net
wrote:

I think that it's useful and valuable to document the current behavior of
OpenSCAD.  But at times when I or others have suggested documenting
something (which, recall, anybody can do since the docs are a wiki), the
response from developers is basically, no, don't document that, because we
might change it some day.  So there's a pressure to avoid documenting
things because they perceive that if it is documented, they can't change it.
You seem to somewhat support this position when you say "It is more
forgivable to define some behavior that was not previously defined than it
is to change a previously documented behavior."  I'm arguing against this
philosophy that we need to avoid documenting any language behaviors that
might change in the future.

Note the point I was making about understanding code is not about code I
wrote, but about other code.  If I encounter code written by someone else
and it has been broken by changes in the language (which is actually
possible already because of changes in 19.05) and I want to fix it, that
will be easier if I have clear documentation of both the old behavior and
the new behavior (presumably the "release notes" you are talking about)
rather than if I only have documentation of the new behavior.

OpenSCAD mailing list-2 wrote

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

Perhaps it should say something like:

The current preview colours are an artefact of the OpenCSG algorithm,
whereby faces take the colour of subtracted objects. This behaviour
should not be relied on and colour should be applied to each volume in its
entirety. I.e. apply color() after any CGS operations have been performed.

On Tue, 7 Apr 2020 at 11:27, adrianv avm4@cornell.edu wrote:

On 07.04.20 12:26, adrianv wrote:

Again, no, you are not reading what I'm trying to say.

See for example this issue:

https://github.com/openscad/openscad/issues/3250

if that would not have been raised as a bug ticket, but
instead documented as "observed behavior". That's no good.
That's not helpful. That makes things worse.

So let me try to clarify yet again:

GOOD:

• Documenting things as they are meant to be, how they
  should work (and hopefully are).
• Documenting APIs

BAD:

• Documenting some observed behavior that may be there due
  to some implementation detail
• Documenting side effects that are not part of the
  intended API

There's more examples like the include file ordering
issue nophead found and fixed not long ago. Preview has
open regression bugs (at least in case of transparency),
documenting that as feature is probably not useful.

ciao,
Torsten.

Isn't   "observed behavior that is not part of the designed
functionality" the actual definition of a bug.

If the behavior is going to be documented, it should documented as an
outstanding issue against that feature.

Nothing wrong with documenting a feature as "function ABC does XYZ
except in some cases as described in Issue 123".

At least the user is warned about using ABC without some test to detect
the failing or misbehaving cases.
It also gives the users a chance to start a discussion about
incorporating the "observed misbehavior" into the API as a feature if it
actually makes ABC more useful.

It also gives the "observed misbehavior" some visibility in the
development community so that it gets fixed before too many users try to
use the "observed misbehavior" as a feature.

Ron

On 2020-04-07 8:13 a.m., Torsten Paul wrote:

--
Ron Wheeler
Artifact Software
438-345-3369
rwheeler@artifact-software.com

On 07.04.20 14:58, Ron Wheeler via Discuss wrote:

No. For example in languages that support introspection,
you can often find out the class hierarchy implementing
things.
So you can rely on the actual type of the implementation
and that works for a while. But it's not part of the
intended public API. So if the implementation changes,
things break even though the public API did not change.

That does not change the fact that you need to define
the intended behavior of XYZ.

See good old Pentium bug. You still describe the feature
as it's supposed to be and you can have an errata
giving known problems. You don't go: Make a list of
result values, including the wrong ones and just
document those as current feature.

ciao,
Torsten.

cacb wrote

Sure, but 3D printing is just one possible use case. I use OpenSCAD a lot,
but not for 3D printing.

I use it for laser cutting, for making plans for building stuff (from
furniture to porch to a holder for my bills...).

In these cases, colors are actually pretty useful.

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

On 2020-04-07 9:27 a.m., Torsten Paul wrote:

That is the choice of the user and they should be aware of the risk that
they are taking by doing this.
There is nothing that the developer of the API can do to protect the
user from changes to the implementation.
The user is not going to get a lot of sympathy from the developers if
they complain that their code no longer functions as they want after an
upgrade (or bug fix) of the implementation.

If accessing hidden implementation details becomes a common practice
needed by many users of an API, then the parts of the implementation
that are needed should be formally exposed in the API and documented.

Not really the case that I was talking about.
My point is really about an accidental misunderstanding of the API
resulting from an unintended behavior that violates the intention of the
API and is not documented officially but has crept into the folklore of
the user community.

Agreed. That was my point.

Agreed.

--
Ron Wheeler
Artifact Software
438-345-3369
rwheeler@artifact-software.com