also on thingiverse is an inkscape extension which exports vector
objects to openscad format directly:

• http://www.thingiverse.com/thing:1065500

Yes it would be nice if we could have lines as first class objects in
OpenSCAD but for now these tools might help you

On 10/4/2016 1:25 PM, Ronaldo wrote:

The reason there is no such thing is that OpenSCAD can not change/set the
variables (set any(!) variable) during  execution.
But the 2d primitives are eaily written by your self.
The 3D primitives are doable too, but a little harder.

2016-10-04 12:51 GMT+02:00 Mark Schafer mschafer@wireframe.biz:

True that all variables are constants, but there could be an operator that
returns the points.  That wouldn't break that paradigm.  Something like:

_2d = points_edges()
intersection()
{
circle(1, $fn=20);
square(2);
}

_3d = points_faces()
intersection()
{
sphere(1, $fn=20);
cube(2);
}

Where:

_2d=[ [point0, point1, ...], [ [edge0, ...], [edge1, ...], ...];
_3d=[ [point0, point1, ...], [ [face0, ...], [face1, ...], ...];

On Tue, Oct 4, 2016 at 8:42 AM, Peter Falke <
stempeldergeschichte@googlemail.com> wrote:

Oh, and further to this, yes, one can write the primitives and the
operators, but that would be reinventing the wheel, and would definitely be
slower.  Especially with things like hull() and minkowski().

The information is available, it just needs to be made available.

Thinking about this further, the operators that I described are actually a
module to function crossover, which doesn't currently exist in OpenSCAD,
but perhaps it could possibly be doable?  Maybe by some incremental build
process?

As I understand it, it currently builds by:

1. calculate all variables/functions
2. calculate all operations/modules.
3. show result on screen result

What I would be suggesting is to iterate over the first 2 steps, executing
each iteration, child node first, up to such crossover points until
everything is calculated, and then do step 3.

Yes, that would be a significant change to the paradigm, but doable?

On Tue, Oct 4, 2016 at 8:42 AM, Peter Falke <
stempeldergeschichte@googlemail.com> wrote:

The problem is that with F5 preview the geometry is never calculated. It is
straight from variables to pixels, so the information is never there unless
you use render().

On 4 October 2016 at 14:32, Adrian H adrianh.bsc@gmail.com wrote:

Oh, that's unfortunate.  But, can not the same idea apply to the preview?
It still has to have points to be able to show the preview, doesn't it?
On Oct 4, 2016 10:00 AM, "nop head" nop.head@gmail.com wrote:

Preview doesn't compute boolean operations points. Try preview cube(10);
rotate(15) sphere(10,$fn=12); with Show edges on. You will see no edges at
the intersection line.

2016-10-05 21:07 GMT-03:00 Adrian H adrianh.bsc@gmail.com:

GPL license now with the code.

On Wed, 5 Oct 2016 18:11:39 -0700
otto otto@123phase.com wrote:

You don't seem to use the @ sign in the places I would expect. I don't see
a need for them in the function definition as any function should be
passable as an argument. I would expect them to be needed where a function
is called from a string, so:

function xsq(x) = x*x;
function recip(x)=1/x;
vec1=[1,2,3];
vec2=[.1,.7];

function map(func,vec) = [for (i=vec) @func(i)];
echo(map("xsq",vec1));
echo(map"("xsq",vec2));
echo(map("recip",vec1));
echo(map("recip",vec2));

The @ sign could also be used to make a function literal instead of passing
string but that is a bigger change to the language. Simply adding @ to take
a string and look up function seems like a simple mod. Creating a new
variable type that is a function would have much bigger implications
because it could be used in any expression. Keeping the name as a string
allows all sorts of tricks by concatenating suffixes, etc.

On 10 October 2016 at 09:53, otto otto@123phase.com wrote:

On Mon, 10 Oct 2016 10:06:50 +0100
nop head nop.head@gmail.com wrote:

The goal was to get what I wanted easily.  The changes are small and
the code seems quite stable.

In declaring a function with the @ decoration.

As in function @xsq(x) = x*x
xsq is an ID token and the variable xsq is given a unique function name
as its contents.  The name is a digit followed by a period.  You can
see it by echoing xsq.

You can then pass xsq around and then dereference it with @.  Because we
use openscads well designed and consistent parsing/compiling environment
to do all the work, this is fast.  As designed I hadn't really
anticipated the side effect that any function can be passed as its token
name, and dereferenced later.  The great thing about this is that the
compiler resolves functions by there string name and all I needed to do
was detect the decorator in the parser and then do one level of
indirection.  The nice thing is it is safe, it doesn't break other code
and it requires only small changes to the source code and it works
now.  Please test the code in the repository if you are inclined or
have the time.

Regards
Otto

So @xsq becomes both a name mangled function and a variable holding its
name? That seems like a bit of a kludge to me.

Defining functions normally and passing them with @name would allow the
compiler to check it was a valid function name without having to have
specially decorated functions. They could be passed as string equal to
their name and then calling @func() could work with any string that equals
a function name. Seems less kludgey to me. You only have one type of
function rather than ones that have to be called normally and ones that
need to be called with @.

On 10 October 2016 at 10:19, otto otto@123phase.com wrote:

On Mon, 10 Oct 2016 10:44:13 +0100
nop head nop.head@gmail.com wrote:

Well its like this, you can pass a function with the name of the
function in quotes.

function div3(x)=x/3;
vec = [1,2,3];

function map(func,vec) = [for (i=vec) @func(i)];
echo(map("div3",vec));

And it works:

Compiling design (CSG Tree generation)...
ECHO: [0.333333, 0.666667, 1]

Using the construct funcion @xyz .., gives you a way to create a
function and have the compiler generate a name for the function and put
it in a variable for you. "@" used in other contexts is simply a
dereferencing operator.  It does require that the name following the
"@" is a variable name known by the compiler and not an expression
returning a string.  "@concat("d","iv3")" will not work.

A syntax that would work nicely (but requires more hacking on my part)
would be to create true anonymous functions with syntax such as follows.

Abandon the "function @...",
shorten it to "@(<argument list>,<function,def>)"
Which returns the created name of the function.  This would allow for
a more anonymous lambda like usage.

Map could then be invoked, map(@(x,x/3),[1,2,3]), which is more compact
and would get the right behavior.

Thanks for the questions and idea.  You are helping me think it
through.  Please try current code.  I think I will try to program
this capability next week. I am going on a trip this week.

BTW what is best way to pass on this code in github.

Regards
Otto

Bananapeel wrote

Yes, I feel that my thread got hijacked somehow.

Bananapeel wrote

Yes, this sounds somewhat reasonable, but these namespaces don't have to
collide.  They can still be (and really should remain) separate, as changing
this could break a lot of scripts.  One can gain access to the function
namespace using that @ sign (or some other sign.  I assume that & wasn't
used for simplicity):

It would also be nice to have proper lambdas:

This syntax would introduce being able to create true lambdas on the fly,
instead of always having to name them and access the function namespace.

--
View this message in context: http://forum.openscad.org/Convert-from-object-to-polygon-polyhedron-tp18522p18662.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Let me summarize current situation:

The following work in my current code:

function map(func,vec) = [for (i=vec) @func(i)];
function @xsq(x) = x*x;
function recip(x)=1/x;
box = "recip";

vec1=[1, 2, 3];
map(box,vec);
map(xsq,vec);

Objections have been:

1. First version using "function @xsq(x)" seems kludgy.
2. One suggestion was the following syntax:

which seems intuitive.
3. (my own objections)  None of these allow for lambda like syntax.

I have a particular problem with my own current code and all
suggestions.  They fail to implement lambda. Suggestion 2 is
essentially the same way that python deals with indirection, Python
provides two methods of creating a function. One method uses a def
statement and the other uses the Lambda construct. They are equivalent
and dereferencing is automatic.

I believe I can get the lambda behavior relatively easily in the current
system. To add lambda syntax I will implement it as:

@(<argumentlist>:<functionDefintion>)

which I think is easier to read than (from python):

lambda <argumentlist>:<functionDefintion>

Either implementation is possible and if enough people request one over
the other, I am willing to implement either.  The first is much simpler
to add for me with my current shallow knowledge of how the code works
and really requires very small changes.

The following would then work:

vec1=[1, 2, 3];
function map(func,vec) = [for (i=vec) @func(i)];
recip = @(x:1/x);
map(recip,vec); //this would work as before
map(@(x,x*x),vec); //this would be using @ as lambda.

I actually believe that the dereferencing of a variable name using "@"
makes the code clearer and easier to maintain and we lose nothing in
terms of capabilities.

If anyone wants to hack the code themselves to obtain any behavior, I
am happy to help point out where in the code changes can be made.
Currently there are only about 30 lines of code that have been added. In
addition, there are some problems currently in my code that could use
some work. I will post these in openscad-affine when I have time.
Collaboration on this is desirable. Incidentally I need these changes
for my work.  The modules in paraSolids are essential for me and need
the function indirection capabilities to work.

For examples of pretty picture please see: ParaSolidExamples.pdf
which is among the files at https://github.com/ottojas/openscad-affine

The repo needs some re-arrangement but I think everything is there..

Thoughts?

I would really like it if someone would test the code I have written.
I am almost exclusively on debian based linux systems.  Debian, Ubuntu
and mint.  I would be happy to build a binary for one of these if that
is what someone willing to test would like.  I am definitely going to
implement the second syntax when i have time (next week at earliest),
that is the "@(<argument list>:<function definition>)" syntax for an
anonymous function.

If requested, I will fork the complete source code setup so you can
compile on any system.  Is that a good idea??

Regards
Otto

On Mon, 10 Oct 2016 12:15:31 -0700 (MST)
Bananapeel lunatica.xiaoyu@gmail.com wrote:

On 10/10/2016 11:15 PM, otto wrote:

Did you see the work Doug did?

https://github.com/doug-moen/openscad2

It's proposing a way to a more powerful language while still
trying to be as compatible as possible.

It would be ideal if we could get the feature aligned with
those efforts. I think it would be a nice thing to get for
current OpenSCAD already.

ciao,
Torsten.

On 10. okt. 2016 19:13, otto wrote:

Sometimes I wonder why OpenSCAD reinvents standard language features of
existing languages... below are some thoughts intended as inspiration.
Your example code is applied to AngelScript, a language I use for 3d
modelling:

funcdef double FUNC(double x);
double div3(double x) { return x/3; }
void map(FUNC @func, double[] @vec)
{ for(uint i=0; i<vec.size(); i++) { vec[i]=func(vec[i]); }  }

void main()
{
double[] vec = { 1,2,3 };
map(div3,vec);
for(uint i=0; i<vec.size(); i++) print(vec[i]+' ');
}

output is the expected:
0.333333 0.666667 1

First, a function signature 'FUNC' is defined, i.e. one taking and
returning a double. Second, an actual function 'div3' with a signature
compatible with FUNC is defined. Third, the 'map' function where the
'func' parameter is passed 'by handle' using @ resembles your code
(alternate syntax "FUNC@ func" also ok). The array 'vec' also passed 'by
handle' so the caller sees the modified 'vec' after calling 'map'

If I had tried to call map using another function, e.g.
double divn(double x, int n) { return x/n; }
it would generate an error because 'divn' is incompatible with the FUNC
signature. It is not clear from your example what happens if you did a
similar mistake.

Just take this comment as food for thought & inspiration.

Regards
Carsten Arnholm

Thanks for reference.  I am new here, found openscad as an ideal
platform for what I wanted to do.  Found some limits and decided to
hack the code.  I am concerned that I may be duplicating others work.
I will read these documents.

I am trying to make the code more powerful and maintain compatibility.
This was intended to meet my own personal needs but I see it as a
possibility for the whole community.

Best Regards
Otto

On Mon, 10 Oct 2016 23:23:28 +0200
Torsten Paul Torsten.Paul@gmx.de wrote:

That is very similar to what I have implemented and what I am
proposing.  I am not familiar with AngelScript.  It looks like in
AngelScript you declare that the argument "func" takes a function.  The
C/C++ like syntax of AngelScript doesn't really (IMHO) fit well with the
untyped and functional nature of OpenScad, but it is interesting to see
another language using @ as an indirection indicator, although it
appears (in AngelScript) in the argument list as a declaration of type
instead of in the body as a declaration of indirection at call time.

Is it possible for AngelScript to implement a function anonymously?
It doesn't look like it from the posted code.

Regards
Otto

On Mon, 10 Oct 2016 23:23:53 +0200
Carsten Arnholm arnholm@arnholm.org wrote:

On 10/10/2016 11:46 PM, otto wrote:

Awesome, that's exactly how I got involved, I really
missed an easy way to add text to a model :-).

There are very likely a number of things from the OpenSCAD2
proposal (and also other ideas) that could be added to the
current state without too much issues. But please don't be
discouraged if it takes some time as language changes are
always a bit tricky. Once something is out, it's very hard
to change.

ciao,
Torsten.

On 2016-10-10 23:57, otto wrote:

Yes, funcdef declares a pointer to function type. If FUNC is defined by
'funcdef', you can declare a variable of type FUNC as a pointer to
function, and assign it:  FUNC@ some_func = div3;

That may be true, but as you say these things are a matter of opinion.
The strong typing in AngelScript is in my opinion an advantage (there
are other advantages as well).

True. I guess in untyped languages that's the only option you have.

Yes, indeed it is possible. See quick example at
http://www.angelcode.com/angelscript/sdk/docs/manual/doc_script_anonfunc.html

Regards
Carsten Arnholm

I've been doing some prototyping work, and after some experiments, my
favourite syntax for anonymous functions is
(x, y) -> x + y

This syntax is naturally nestable, so it's easy to write a "curried"
function like this:
x -> y -> x + y
[In my prototype, the parentheses around a parameter list are optional if
the entire parameter list consists of just a single identifier.]

Otto's "map" example would be written
map(x->x/3, [1,2,3])

On 10 October 2016 at 13:13, otto otto@123phase.com wrote:

Bananapeel wrote:

I agree with this.

If we implement function values without uniting the namespaces, we have to
use ugly, nonstandard syntax for things like: calling a function stored in
a variable, or passing a named function as an argument. This leads to
complicated rules and ugly syntax, worse than function calls in any modern
programming language. And that's not in the spirit of OpenSCAD, which aims
to be simpler than a general purpose programming language.

Thought experiment: what happens if we change OpenSCAD to use 1 namespace
in the next release? Answer: we'd break some existing code, and that
happens in two ways:

1. If you define a function and a variable with the same name X, in the
   same scope, then the code no longer works. We should report an error
   (duplicate definition of X).
2. Currently, a variable defined in an inner scope cannot  shadow a
   variable defined in an outer scope, and vice versa. Once we unify the
   namespaces, the scoping rules change, and this sort of shadowing will
   occur. And this could be a silent error?

So maybe we should make this change in two phases, first deprecating the 3
namespaces, then uniting them in a subsequent release?

1. In release N, we'll deprecate the 3 namespaces. You'll get a warning
   for duplicate definitions in the same scope, and a warning for objects with
   different kinds but the same name shadowing each other in nested scopes.
2. In release N+1, these warnings turn into errors. We won't silently
   change the meaning of old code: instead, we'll detect the old incompatible
   code, report an error and force you to fix it. In this release, we can also
   make functions into first class values, and introduce a syntax for
   anonymous functions. Although the namespaces are now unified, modules won't
   necessarily be first class values (that's harder to do, and I won't discuss
   the details here).

Even with the deprecation release, this is a disruptive change that breaks
existing code. It's more work, but we could mitigate the problem by
providing an upgrade tool that automatically renames objects to avoid
conflicts. (For example, the tool could append a V, F or M to the names of
variables, functions and modules that conflict with one another.) If the
upgrade tool is painless enough to use, maybe we don't need the deprecation
phase?

This is the simplest path I can think of that leads to function values with
a unified namespace. The backwards compatibility scheme I described in the
OpenSCAD2 proposal is much harder to implement.

Doug Moen.

On 10 October 2016 at 15:15, Bananapeel lunatica.xiaoyu@gmail.com wrote:

Breaks all my code as I use lots of single names for both a variable, a
function that exports it and module that it relates to. I find it handy not
to make up three names for one subject. It is obvious which one is
referenced from the context.

If there is a breaking change to OpenScad I will stick with the version I
have now forever as it does everything I need. Same as Python 2, never used
3 as I need to change all my print statements to functions. Please make
such big changes in OpenScad2.

On 14 October 2016 at 23:07, Mark Schafer mschafer@wireframe.biz wrote:

nophead wrote

nice: :

--
View this message in context: http://forum.openscad.org/Convert-from-object-to-polygon-polyhedron-tp18522p18714.html
Sent from the OpenSCAD mailing list archive at Nabble.com.