On 02.07.19 18:52, adrianv wrote:

No, you can't. Well nobody can force you to stop poking
holes in places that are not clearly defined, there's
definitely lots of those. But you have to keep the pieces
when it breaks ;-).

ciao,
Torsten.

On 02.07.19 20:09, adrianv wrote:

Yes, and that's what I meant. Things are not clearly specified
so there are lots of undefined places. The first tiny steps for
reducing that are the latest improvements implementing warnings
for a number of those cases.

So I guess there's 2 options:

1. Define all the holes as feature and basically make it impossible
   to change the OpenSCAD language.

2. Slowly move to a clearer specification by improving both code
   and documentation.

I hope we will end up with the 2nd option, and I hope people will
help going into that direction.

ciao,
Torsten.

tp3 wrote

So what should the behavior be for multmatrix()?  It should be an error to
pass a matrix not exactly 4x4?  One could argue that being able to pass 3x3
is not unreasonable.  I tend to think that excess data should be an error,
e..g passing a 5x5 shouldn't be accepted, but it's not obvious that the
current behavior is otherwise bad.  Is there harm in alllowing a matrix
subset?  (If I were to pick a place where I thought we would get significant
benefit from the efforts of an OpenSCAD programming, I certainly wouldn't
point to this issue.)

What's the bottom line for the "approved" ways to use multmatrix()?

I don't have a feeling like OpenSCAD is really moving anywhere, like I
should have an expectation that it will improve.  The fact that 4 years
passed between releases suggests a pretty conservative approach, without
much change.  It seems like  suggestions of changes are met with the
response that those who could execute such changes lack the time or
inclination to do so (and that it's unreasonable to request changes because
it's a volunteer effort.)  So it's really not apparent how someone (who is
not prepared to write code for OpenSCAD itself) could help improve matters
in the core language.

Here's another observation: if behavior is not documented then perhaps it
decreases the likelihood of code relying on that behavior, but also it's
difficult for people to observe that the behavior is bad, since it's secret.
It seems unlikely to get "fixed".  Perhaps behavior deemed bad should be
documented as "quirks" or something like that, with the indication that
quirk behavior may change in the future, and code should avoid relying on
it.  Or does someone already have a list of these sorts of concerns?

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

…

I neither have the time nor intellect to write code for OpenSCAD, but I sure appreciate the effort
that has gone into it.

I have a friend who does a lot of volunteer shareware software development. His programs get downloaded about 20K
a month, but in the 12 years he’s been doing it, he’s gotten about $200 in total whereas on the other hand the request
for new features or complaints about how his programs don’t do one thing or another are endless. I know for a fact he’s pretty
pleased when he gets that very infrequent email of thanks and/or praise.
So for part I try to let the developers know how much I appreciate the time and effort they put into this project.

I know OpenSCAD isn’t perfect, and I’m pretty sure the developers are even more aware of its imperfections than I am, but
for a variety of reasons OpenSCAD is my development environment of choice and I’d hate to see it wither and die.

Secondly… there’s cash. :) To show my support I make a (currently very modest) monthly donation to OpenSCAD which
I hope to increase as my own resources permit. I’ve spent far more on a 3D printer than I’ve spent using the program that
I consider indispensable to creating object to print on it… I don’t think that’s quite right.

Thirdly, there’s bounties and I know if I’m really serious about an extension or feature, I could offer a reward. I note that some
feature requests with a bounty will sometimes even see others joining in to up the ante and make it even more
worthwhile for someone with the knowledge and expertise to actually do the work. Granted most of the bounties offered
seem to be in the < $50 range… but I wonder how excited one of the developers might be If one were to offer something like
$200, $500 or $1000 for something to be implemented.
Something at that level might be out of my range, but I’ve been toying with the idea of offering a bounty that would serve
as a serious thank you for the time and effort it would take for a feature I’d very much like to see.

boxcarmib wrote

The project I wrote and and have supported for the last 23 years is on most
or all linux computers and also (in a very early version) on all mac
computers.  It's kind of hard to tell how many users there are.  I've gotten
exactly $0 from my efforts.  On doesn't undertake volunteer work with the
expectation of getting money out of it.

I have no idea how this sort of cash award affects developers.  I mean, if
the developers have day jobs then offering $50 for a feature that takes ten
hours of work is sort of insulting, since it means $5/hour.  There are
studies done about how offering money for things can shift perception and
behavior as it moves the behavior from a friend interaction to an economic
one.  (Do you offer your friend money to help move a piece of furniture?)
Of course, if a developer does not have a paying job perhaps getting $50 is
a big draw.  And I wouldn't suggest that people don't offer money if they
choose.  But ultimately, working on a project like mine, or like OpenSCAD is
volunteer work, and one must choose to do it for the interest, enjoyment,
and/or feeling of making a contribution to the community.

In the case of OpenSCAD, there's no roadmap that I've seen describing which
features the developers are interested in actually implementing.  In my
experience, if I have an idea of how the program might be improved and I
suggest it first it's met with a kind of hostile reaction about how I
shouldn't expect anything, and secondly, it's already been suggested many
times by others.  I found what seemed to me to be a major bug and discovered
it was already reported and had been open for years.  So all of this makes
it seem like change is unlikely.  This is an observation, not a criticism
of the developers.  And it doesn't make a whole lot of sense to wait around
for the 2023 release.

That's why the question is: what does OpenSCAD do now, so I can use it best?
How does multmatrix() work?  How are we supposed to use it?  I didn't start
this discussion to be a debate about OpenSCAD development, but rather to
figure out how I can and should use multmatrix().  And also possibly I
thought I might improve the manual to better describe how multmatrix()
works, since that's something I can do to help others.  But it looks like
maybe this effort is also not appreciated, or is controversial---the
response that seems to arise for all efforts to help the OpenSCAD project.
So I guess I won't bother.  It's pretty hard to make a contribution.

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

The code
https://github.com/openscad/openscad/blob/69bf5a55475102be43c2ddc698198e85821332b3/src/transform.cc#L204
creates
a 4x4 identity matrix and then for each element it looks to see if the
corresponding element exists in the passed matrix and if it does it
overwrites that entry.

So basically it tries as hard as it can to convert any shape matrix to fit.
Any element it can't find is left as the value from the identity. If the
argument isn't even a matrix it silently uses the identity.

On Wed, 3 Jul 2019 at 13:15, adrianv avm4@cornell.edu wrote:

This sounds like pretty intentional behavior.  Is there a prevailing (or at
least common) belief that it's wrong and needs to change?

nophead wrote

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

I think it should warn if you don't pass a vector of vectors, but other
than that, what is the point in tightening up the size requirements?

On Wed, 3 Jul 2019 at 22:24, adrianv avm4@cornell.edu wrote: