I don't understand your comment. The new echo expression is not yet present
in any released version, so changing the behaviour at this point will not
break backward compatibility. The existing echo statement in the release
version doesn't introduce local variable bindings.

So I don't understand why echo would need to be renamed.

Please don't get rid of echo and "ECHO:". I use that to extract meta data
for years while there are endless arguments as to how to do that.

On 3 April 2016 at 16:40, Torsten Paul Torsten.Paul@gmx.de wrote:

On 04/03/2016 05:59 PM, doug moen wrote:

We certainly don't want to have statement level and function
level echo() that behave totally different. But moving into
the direction of unifying functions and modules, it would
make lots of sense to have one way for the debug output that
works for both.

I'm not talking about renaming the existing statement level
echo(). That would stay exactly as it is now.

ciao,
Torsten.

nophead wrote

As I mentioned in an  earlier post
http://forum.openscad.org/In-console-documentation-td8219.html  that the
display of "ECHO:" gives me headache when I work on the in-console doc.

Maybe it'd be a good idea to have an option so user can disable the display
of "ECHO:" on the document basis ? Something like a special comment as a
directive:

// # DISPLAY_ECHO = 0

It'd be then possible to turn it off in a file that you don't need it.

$  Runsun Pan, PhD $ libs: doctest , faces ( git ), offline doc ( git ), runscad.py( 1 , 2 , git ), synwrite( 1 , 2 );  $ tips: hash( 1 , 2 ), matrix( 1 , 2 ),sweep( 1 , 2 ), var( 1 , 2 ), lerp , animation ( gif , prodVid ), precision( 1 , 2 ), xl-control , type , rounded polygon , chfont

--
View this message in context: http://forum.openscad.org/Simple-polygon-triangulation-tp16755p16935.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Thinking about I I could add "BOM:" to my echo statements to avoid relying
on ECHO:.

On 3 April 2016 at 18:58, runsun runsun@gmail.com wrote:

I’ve often found myself wishing for standard-issue printf() support, e.g. ‘printf(“BOM: item %s, qty %d\n”, item_name, item_qty);’

--

"The future is already here.  It's just not very evenly distributed" -- William Gibson

Me: http://clothbot.com/wiki/ http://clothbot.com/wiki/

Torsten:

For consistency and backward compatibility, what I suggest is:

At the statement level,
echo(args);
is a statement that does whatever it does now. In other words, no change.

At the expression level,
echo(args) expr
is an expression that echoes whatever 'echo(args);' echoes as a statement,
then returns the result of evaluating expr, without introducing local
variable bindings into expr.

At the list comprehension level,
echo(args) generator
is a generator that echoes whatever 'echo(args);' echoes, then runs
'generator' to create list elements, without introducing local variable
bindings into 'generator'.

For consistency with the expression and generator form of echo, we can also
support
echo(args) statement
as a statement.

This is just a conservative extension to echo() so you can put debug
statements anywhere. It's doesn't improve the output of echo() in any way.
That's a more ambitious and controversial project that would require more
discussion and a new name (to preserve backward compatibility).

On 04/03/2016 08:22 PM, doug moen wrote:

Why introduce something we know is already deprecated when it's
written? Considering the very limited amount of dev time available,
I'm not a huge fan of that.

ciao,
Torsten.

Parkinbot wrote

You are right. However, to reduce the time complexity there we will need to
organize the information in adequate data structures and this may be very
complex. I devise a simple data structure that may cut the time spent in ear
tests since the test is done just once per ear. But I will return now to my
Bezier stuff to finish it before implement that idea. If you want to try, I
can tell you how. But I don't believe it will reduce the time complexity to
O(n^2).

Parkinbot wrote

For any two plane adjustment methods, it is possible to devise a set of
points for which anyone of them fail. Even with almost planar points. And
certainly for points following a knot path, any method will fail.

I have evaluated the time spent by the method I implemented. First, time is
linear for up to 4000 points. For more than that, I got a stack overflow in
a recursive list processing function. For 4000 points, the eigenvalue method
spent about 0.5 sec in my outdated machine. That is fine to me (the
evaluation, not the machine :-) ).

Regarding the stack overflow: the function in question is a simple summation
of the elements of a list. OpenSCAD has only lists as data structure.
However, the set of list processing functions is a bare minimum. And
recursion is the only way to implement some functions in OpenSCAD. It is
elegant but the stack ... I would expect that OpenSCAD had other list
processing functions like: head, tail, sub_list, sum_list, invert, sort,
remove_sub_list, etc. Yes, they may be coded in user space but len and
lookup as well. And they are much more useful then lookup.

--
View this message in context: http://forum.openscad.org/Simple-polygon-triangulation-tp16755p16940.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

On 04/04/2016 12:55 AM, Ronaldo wrote:

OpenSCAD can do simple tail recursion elimination, so if the
function is matching the simple "cond ? result : recurse()"
it will not be limited by stack (there's still a loop limit
but that's much higher... a million, I think?).

// no tail recursion elimination possible, on my system
// that runs out of stack at list length of about 11000.
function sum(l, idx = 0) = idx >= len(l)
? 0
: l[idx] + sum(l, idx + 1);

echo(sum([each [1 : 10000]]));

// with tail recursion elimination, half a million loops
// take a second or two, but will not crash due to stack
// limit.
function sum_tr(l, idx = 0, ret = 0) =  idx >= len(l)
? ret
: sum_tr(l, idx + 1, ret + l[idx]);

echo(sum_tr([each [1 : 500000]]));

ciao,
Torsten.