Empathy List Archives

DM

doug moen

Mon, Oct 17, 2016 2:53 PM

The @ syntax doesn't work for me, because it only works for functions, not
for modules.

There's been a long history of people asking for operations that take
shapes as arguments, and return values. For example, there's a very recent
forum thread asking for an operation that tests if two shapes intersect,
returning a boolean.

if (intersects(cube(v), children(0)) ...

We can't implement these operations because there's no reasonable syntax
for it, but there would be no problem if we had a unified namespace.

There are 4 solutions to this problem.

The simplest solution, as I said before, is to deprecate the 3
namespaces, and then finally unify the namespaces in a future release. It's
simple because no new syntax is required. There is a backward compatibility
issue, because a small percentage of old scripts (the ones that take
advantage of the 3 namespaces by defining the same name twice) would have
to be upgraded to use distinct names.

The other 3 solutions provide better backward compatibility.

We can introduce some new syntax: namespace qualifiers, which decorate
an identifier and specify which namespace it belongs to. It's inherently
confusing and ugly, no matter what decorator syntax we choose, but it's one
way to support backward compatibility. This approach, by itself, does not
let people write code where all names are in a single unified namespace,
and that's what I really want. If we provide namespace qualifiers in
conjunction with some other solution that lets me write scripts where all
names are in a single namespace, then I don't object to them.

Here is the syntax I've been playing with. There are 3 namespace prefixes:
v$ f$ m$. For example:

// define a function, in the function namespace, by computing it.
f$foo = some_expression_that_computes_a_function_value();

// pass a function as an argument to another function
map(f$foo, list)

// call a variable as a function
function map(f, list) = [ for (x = list) v$f(x) ];

// call a module in an expression context
if (intersects(m$cube(v), m$children(0)) ...

Introduce a "pragma" statement that you write as the first line of a
script, specifying whether all identifiers are in a single namespace, or in
3 namespaces. This provides pretty good backwards compatibility. If the
default is the single namespace, then that's the best solution going
forward for new code (a single namespace is simpler and easier to
understand), but some old scripts will need to be modified to add the
pragma.
The OpenSCAD2 solution that I proposed last year. Old scripts that use 3
namespaces continue to work, without modification. There is a new syntax
for function and module definitions. If you use the new definition syntax,
the script is interpreted in single-namespace mode. If you use the old
definition syntax, the script is interpreted in 3-namespace mode. No pragma
is required. This provides backwards compatibility, and supports both
styles of coding: the 3-namespace style, and the 1-namespace style.

On 17 October 2016 at 07:58, Richard Urwin <soronlin+openscad@googlemail.com

wrote:

ottojas wrote

Here is an example of openScad code using the new syntax.

function reduce(func,vec) =
len(vec)==2 ? @func(vec[0],vec[1]) : @func(vec[0],reduce(func,[for
(i=[1:len(vec)-1]) vec[i]]));

echo(reduce(@(x,y:x+y),[1,2,3,4,5]));
echo(reduce(@(x,y:x*y),[1,2,3,4,5]));

cossin=@(x,y:sin(x)-cos(y));
echo(reduce(cossin,[1,2,3,4,5]));

/**************************
RESULT
ECHO: 15
ECHO: 120
ECHO: -0.982406
**************************/

The @ in the indirect call is required for backwards compatibility but
every
other use of @ could be replaced by "function", making your code:

function reduce(func,vec) =
len(vec)==2 ? @func(vec[0],vec[1]) : @func(vec[0],reduce(@func,[for
(i=[1:len(vec)-1]) vec[i]]));

echo(reduce(function(x,y:x+y),[1,2,3,4,5]));
echo(reduce(function(x,y:x*y),[1,2,3,4,5]));

cossin=function(x,y:sin(x)-cos(y));
echo(reduce(cossin,[1,2,3,4,5]));

To my mind, that is more readable.
Then, if eventually the namespaces are merged, the @ could be deprecated
and
phased out.

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

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

The @ syntax doesn't work for me, because it only works for functions, not for modules. There's been a long history of people asking for operations that take shapes as arguments, and return values. For example, there's a very recent forum thread asking for an operation that tests if two shapes intersect, returning a boolean. if (intersects(cube(v), children(0)) ... We can't implement these operations because there's no reasonable syntax for it, but there would be no problem if we had a unified namespace. There are 4 solutions to this problem. 1. The simplest solution, as I said before, is to deprecate the 3 namespaces, and then finally unify the namespaces in a future release. It's simple because no new syntax is required. There is a backward compatibility issue, because a small percentage of old scripts (the ones that take advantage of the 3 namespaces by defining the same name twice) would have to be upgraded to use distinct names. The other 3 solutions provide better backward compatibility. 2. We can introduce some new syntax: namespace qualifiers, which decorate an identifier and specify which namespace it belongs to. It's inherently confusing and ugly, no matter what decorator syntax we choose, but it's one way to support backward compatibility. This approach, by itself, does *not* let people write code where all names are in a single unified namespace, and that's what I really want. If we provide namespace qualifiers in conjunction with some other solution that lets me write scripts where all names are in a single namespace, then I don't object to them. Here is the syntax I've been playing with. There are 3 namespace prefixes: v$ f$ m$. For example: // define a function, in the function namespace, by computing it. f$foo = some_expression_that_computes_a_function_value(); // pass a function as an argument to another function map(f$foo, list) // call a variable as a function function map(f, list) = [ for (x = list) v$f(x) ]; // call a module in an expression context if (intersects(m$cube(v), m$children(0)) ... 3. Introduce a "pragma" statement that you write as the first line of a script, specifying whether all identifiers are in a single namespace, or in 3 namespaces. This provides pretty good backwards compatibility. If the default is the single namespace, then that's the best solution going forward for new code (a single namespace is simpler and easier to understand), but some old scripts will need to be modified to add the pragma. 4. The OpenSCAD2 solution that I proposed last year. Old scripts that use 3 namespaces continue to work, without modification. There is a new syntax for function and module definitions. If you use the new definition syntax, the script is interpreted in single-namespace mode. If you use the old definition syntax, the script is interpreted in 3-namespace mode. No pragma is required. This provides backwards compatibility, and supports both styles of coding: the 3-namespace style, and the 1-namespace style. On 17 October 2016 at 07:58, Richard Urwin <soronlin+openscad@googlemail.com > wrote: > ottojas wrote > > Here is an example of openScad code using the new syntax. > > > > function reduce(func,vec) = > > len(vec)==2 ? @func(vec[0],vec[1]) : @func(vec[0],reduce(func,[for > > (i=[1:len(vec)-1]) vec[i]])); > > > > echo(reduce(@(x,y:x+y),[1,2,3,4,5])); > > echo(reduce(@(x,y:x*y),[1,2,3,4,5])); > > > > cossin=@(x,y:sin(x)-cos(y)); > > echo(reduce(cossin,[1,2,3,4,5])); > > > > /************************** > > RESULT > > ECHO: 15 > > ECHO: 120 > > ECHO: -0.982406 > > **************************/ > > The @ in the indirect call is required for backwards compatibility but > every > other use of @ could be replaced by "function", making your code: > > function reduce(func,vec) = > len(vec)==2 ? @func(vec[0],vec[1]) : @func(vec[0],reduce(@func,[for > (i=[1:len(vec)-1]) vec[i]])); > > echo(reduce(function(x,y:x+y),[1,2,3,4,5])); > echo(reduce(function(x,y:x*y),[1,2,3,4,5])); > > cossin=function(x,y:sin(x)-cos(y)); > echo(reduce(cossin,[1,2,3,4,5])); > > > To my mind, that is more readable. > Then, if eventually the namespaces are merged, the @ could be deprecated > and > phased out. > > > > -- > View this message in context: http://forum.openscad.org/ > Convert-from-object-to-polygon-polyhedron-tp18522p18752.html > Sent from the OpenSCAD mailing list archive at Nabble.com. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > >

RU

Richard Urwin

Mon, Oct 17, 2016 3:23 PM

doug.moen wrote

Introduce a "pragma" statement that you write as the first line of a
script, specifying whether all identifiers are in a single namespace, or
in
3 namespaces. This provides pretty good backwards compatibility. If the
default is the single namespace, then that's the best solution going
forward for new code (a single namespace is simpler and easier to
understand), but some old scripts will need to be modified to add the
pragma.

Suppose instead, we mandated a first line for new programs. Let's make it
useful and specify a language version:

OpenSCAD 1.9

Then if that line is not present, all function names are prefixed "F_", all
modules are prefixed "M_" and all variables (and identifiers in expressions
not followed by open-parenthesis) are prefixed "V_". That creates three
namespaces for very low cost.

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

doug.moen wrote > 3. Introduce a "pragma" statement that you write as the first line of a > script, specifying whether all identifiers are in a single namespace, or > in > 3 namespaces. This provides pretty good backwards compatibility. If the > default is the single namespace, then that's the best solution going > forward for new code (a single namespace is simpler and easier to > understand), but some old scripts will need to be modified to add the > pragma. Suppose instead, we mandated a first line for new programs. Let's make it useful and specify a language version: OpenSCAD 1.9 Then if that line is not present, all function names are prefixed "F_", all modules are prefixed "M_" and all variables (and identifiers in expressions not followed by open-parenthesis) are prefixed "V_". That creates three namespaces for very low cost. -- View this message in context: http://forum.openscad.org/Convert-from-object-to-polygon-polyhedron-tp18522p18756.html Sent from the OpenSCAD mailing list archive at Nabble.com.

O

otto

Mon, Oct 17, 2016 8:26 PM

I have no problem with a "function" syntax, or a "lambda" syntax for
that matter:

echo(reduce(lambda(x,y:x+y),[1,2,3,4,5]));

Which has the advantage that a casual reader may catch on to the syntax
quicker, since the meaning of "lambda" and lambda functions have a
long history.

I am willing to change the syntax in my test code to whatever if folks
are willing to commit to download install and try. If
someone wants to use this capability now, then I am willing to
implement it in a way they like, so it can be tested in practice. I am somewhat
concerned that my syntax will be passed by on the next newer and better
version of OpenScad and will be obsolete. It seems that there is
very little work going on at the moment to expand the syntax. That
speaks loads about the excellent quality of the current syntax and
code, since it is clearly being used widely. There are only a few
improvements that seem obvious to me, one being anonymous and indirect
functions. This improvement is recommended do to actual need as
opposed to theoretical reasons.

I have forked/cloned the openscad system to a new repository at:

https://github.com/ottojas/openscad

This is only for the sake of making it easy to download an compile
reliably. I am unfamiliar with github and the ethics of cooperation on
the open source site, so forgive me and inform me if this is the wrong
approach to getting new code into the world and tested.

Re namespaces:

I like the non-unified name spaces, although unconventional it works
for me.

Torsten wrote:

I don't think we have a problem at definition time,
the trouble is where the data is passed to another
function (or module).

He is absolutely right on this.

The "@" dereference operator is needed in order to
move a reference to a function from the non-function
namespace to an actual function in the function namespace. Explicit
dereferencing is not necessarily bad and used extensively in other
languages. Unifying the namespaces discourages certain operations, and
encourages others, but in reality there are no common operations such as
"+" that have any meaning between objects in the seperate namespaces
of openscad. Objects in one namespace, do not move easily into the
others without some form of explicit conversion.

Note that: the meaning of:

reduce = function(func,vec:
len(vec)==2

      ? @func(vec[0],vec[1])

     : @func(vec[0],@reduce(func,[for (i=[1:len(vec)-1]) vec[i]]))
              );

echo(@reduce(function(x,y:x*y),[1,2,3,4,5]));

Is clear, and in my opinion even clearer if we use "@" both to declare
the anonymous function and to dereference since it impies our
intentions and directs us to to expect "reduce" to be used with the
dereference "@" when it is used. I also like the compactness of "@"
over either "lambda" or "function".

reduce = @(func,vec:
len(vec)==2

      ? @func(vec[0],vec[1])

     : @func(vec[0],@reduce(func,[for (i=[1:len(vec)-1]) vec[i]]))
              );

echo(@reduce(@(x,y:x*y),[1,2,3,4,5]));

Personally, I see little advantage in merging the namespaces since the
current design works, is simple and easy to maintain and in addition
adding indirection is trivial. Unifying the namespaces raises a
plethora of other issues. The only remaining issue is one of what the
syntax looks like, not what it does.

Who else is working on the OpenScad C++/parser code here and what are
they doing? I note that there are many places in the code marked with

	// FIXME: <comment>

I hope to deal with a few of these as well. Is anyone else working on
these?

Current Test Code for:
https://github.com/ottojas/openscad

/////////////////////////////
reduce = @(func,vec:
len(vec)==2 ? @func(vec[0],vec[1]) :
@func(vec[0],@reduce(func,[for (i=[1:len(vec)-1]) vec[i]]))
);

echo(@reduce(@(x,y:x+y),[1,2,3,4,5]));
echo(@reduce(@(x,y:x*y),[1,2,3,4,5]));
cossin=@(x,y:sin(x)-cos(y));
echo(@reduce(cossin,[1,2,3,4,5]));

/**************************
RESULT
ECHO: 15
ECHO: 120
ECHO: -0.982406
**************************/
///////////////////////////////

Regards
Otto

On Mon, 17 Oct 2016 04:58:38 -0700 (MST)
Richard Urwin soronlin+openscad@googlemail.com wrote:

ottojas wrote

Here is an example of openScad code using the new syntax.

function reduce(func,vec) =
len(vec)==2 ? @func(vec[0],vec[1]) :
@func(vec[0],reduce(func,[for (i=[1:len(vec)-1]) vec[i]]));

echo(reduce(@(x,y:x+y),[1,2,3,4,5]));
echo(reduce(@(x,y:x*y),[1,2,3,4,5]));

cossin=@(x,y:sin(x)-cos(y));
echo(reduce(cossin,[1,2,3,4,5]));

/**************************
RESULT
ECHO: 15
ECHO: 120
ECHO: -0.982406
**************************/

The @ in the indirect call is required for backwards compatibility
but every other use of @ could be replaced by "function", making your
code:

function reduce(func,vec) =
len(vec)==2 ? @func(vec[0],vec[1]) :
@func(vec[0],reduce(@func,[for (i=[1:len(vec)-1]) vec[i]]));

echo(reduce(function(x,y:x+y),[1,2,3,4,5]));
echo(reduce(function(x,y:x*y),[1,2,3,4,5]));

cossin=function(x,y:sin(x)-cos(y));
echo(reduce(cossin,[1,2,3,4,5]));

To my mind, that is more readable.
Then, if eventually the namespaces are merged, the @ could be
deprecated and phased out.

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

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

I have no problem with a "function" syntax, or a "lambda" syntax for that matter: echo(reduce(lambda(x,y:x+y),[1,2,3,4,5])); Which has the advantage that a casual reader may catch on to the syntax quicker, since the meaning of "lambda" and lambda functions have a long history. I am willing to change the syntax in my test code to whatever if folks are willing to commit to download install and try. If someone wants to use this capability now, then I am willing to implement it in a way they like, so it can be tested in practice. I am somewhat concerned that my syntax will be passed by on the next newer and better version of OpenScad and will be obsolete. It seems that there is very little work going on at the moment to expand the syntax. That speaks loads about the excellent quality of the current syntax and code, since it is clearly being used widely. There are only a few improvements that seem obvious to me, one being anonymous and indirect functions. This improvement is recommended do to actual need as opposed to theoretical reasons. I have forked/cloned the openscad system to a new repository at: https://github.com/ottojas/openscad This is only for the sake of making it easy to download an compile reliably. I am unfamiliar with github and the ethics of cooperation on the open source site, so forgive me and inform me if this is the wrong approach to getting new code into the world and tested. Re namespaces: I like the non-unified name spaces, although unconventional it works for me. Torsten wrote: > I don't think we have a problem at definition time, > the trouble is where the data is passed to another > function (or module). He is absolutely right on this. The "@" dereference operator is needed in order to move a reference to a function from the non-function namespace to an actual function in the function namespace. Explicit dereferencing is not necessarily bad and used extensively in other languages. Unifying the namespaces discourages certain operations, and encourages others, but in reality there are no common operations such as "+" that have any meaning between objects in the seperate namespaces of openscad. Objects in one namespace, do not move easily into the others without some form of explicit conversion. Note that: the meaning of: >reduce = function(func,vec: > len(vec)==2 ? @func(vec[0],vec[1]) > : @func(vec[0],@reduce(func,[for (i=[1:len(vec)-1]) vec[i]])) > ); > > echo(@reduce(function(x,y:x*y),[1,2,3,4,5])); Is clear, and in my opinion even clearer if we use "@" both to declare the anonymous function and to dereference since it impies our intentions and directs us to to expect "reduce" to be used with the dereference "@" when it is used. I also like the compactness of "@" over either "lambda" or "function". >reduce = @(func,vec: > len(vec)==2 ? @func(vec[0],vec[1]) > : @func(vec[0],@reduce(func,[for (i=[1:len(vec)-1]) vec[i]])) > ); > > echo(@reduce(@(x,y:x*y),[1,2,3,4,5])); Personally, I see little advantage in merging the namespaces since the current design works, is simple and easy to maintain and in addition adding indirection is trivial. Unifying the namespaces raises a plethora of other issues. The only remaining issue is one of what the syntax looks like, not what it does. Who else is working on the OpenScad C++/parser code here and what are they doing? I note that there are many places in the code marked with // FIXME: <comment> I hope to deal with a few of these as well. Is anyone else working on these? Current Test Code for: https://github.com/ottojas/openscad ///////////////////////////// reduce = @(func,vec: len(vec)==2 ? @func(vec[0],vec[1]) : @func(vec[0],@reduce(func,[for (i=[1:len(vec)-1]) vec[i]])) ); echo(@reduce(@(x,y:x+y),[1,2,3,4,5])); echo(@reduce(@(x,y:x*y),[1,2,3,4,5])); cossin=@(x,y:sin(x)-cos(y)); echo(@reduce(cossin,[1,2,3,4,5])); /************************** RESULT ECHO: 15 ECHO: 120 ECHO: -0.982406 **************************/ /////////////////////////////// Regards Otto On Mon, 17 Oct 2016 04:58:38 -0700 (MST) Richard Urwin <soronlin+openscad@googlemail.com> wrote: > ottojas wrote > > Here is an example of openScad code using the new syntax. > > > > function reduce(func,vec) = > > len(vec)==2 ? @func(vec[0],vec[1]) : > > @func(vec[0],reduce(func,[for (i=[1:len(vec)-1]) vec[i]])); > > > > echo(reduce(@(x,y:x+y),[1,2,3,4,5])); > > echo(reduce(@(x,y:x*y),[1,2,3,4,5])); > > > > cossin=@(x,y:sin(x)-cos(y)); > > echo(reduce(cossin,[1,2,3,4,5])); > > > > /************************** > > RESULT > > ECHO: 15 > > ECHO: 120 > > ECHO: -0.982406 > > **************************/ > > The @ in the indirect call is required for backwards compatibility > but every other use of @ could be replaced by "function", making your > code: > > function reduce(func,vec) = > len(vec)==2 ? @func(vec[0],vec[1]) : > @func(vec[0],reduce(@func,[for (i=[1:len(vec)-1]) vec[i]])); > > echo(reduce(function(x,y:x+y),[1,2,3,4,5])); > echo(reduce(function(x,y:x*y),[1,2,3,4,5])); > > cossin=function(x,y:sin(x)-cos(y)); > echo(reduce(cossin,[1,2,3,4,5])); > > > To my mind, that is more readable. > Then, if eventually the namespaces are merged, the @ could be > deprecated and phased out. > > > > -- > View this message in context: > http://forum.openscad.org/Convert-from-object-to-polygon-polyhedron-tp18522p18752.html > Sent from the OpenSCAD mailing list archive at Nabble.com. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

TP

Torsten Paul

Mon, Oct 17, 2016 9:56 PM

On 10/17/2016 10:26 PM, otto wrote:

I am somewhat concerned that my syntax will be passed
by on the next newer and better version of OpenScad and
will be obsolete.

Trying this out will help to get a feeling of how it works
and maybe find potential issues, that's very useful.

For integration we should try finding a way that is
compatible with the ideas for a future language version.
It's likely going to be quite some time until a new
language version will happen, still making the task
unnecessary difficult is not a good idea.

It seems that there is very little work going on at the
moment to expand the syntax. That speaks loads about the
excellent quality of the current syntax and code, since
it is clearly being used widely.

I can only speak for myself, but the reason for very little
going on is totally to blame on lack of spare time.

Also there's always the concern of breaking scripts, so
syntax changes are slower than other changes.

This is only for the sake of making it easy to download
an compile reliably. I am unfamiliar with github and the
ethics of cooperation on the open source site, so forgive
me and inform me if this is the wrong approach to getting
new code into the world and tested.

Working from github certainly makes things easier, I'll
try to build some special Windows snapshots for people
who just want to give it a try. Might take a couple of
days though...

If you want to chat a bit more interactively, you can
find Marius (nickname kintel) and me (nickname teepee)
quite often in the #openscad IRC channel on freenode.
Just say hello and hang around a bit, someone will
notice eventually.

http://webchat.freenode.net/?channels=openscad

Small note on git/github usage, it will probably help to
work on changes in a separate branch instead of directly
using master. It's usually better to merge things in
smaller changes that belong to a single topic (via pull
requests). If everything is just committed to master,
it's much more complicated as everything is mixed together.

Who else is working on the OpenScad C++/parser code here
and what are they doing?

I'm not aware of bigger changes going on in the parser,
I think the latest bigger change was about better line
number tracking and that is in master now.

ciao,
Torsten.

On 10/17/2016 10:26 PM, otto wrote: > I am somewhat concerned that my syntax will be passed > by on the next newer and better version of OpenScad and > will be obsolete. > Trying this out will help to get a feeling of how it works and maybe find potential issues, that's very useful. For integration we should try finding a way that is compatible with the ideas for a future language version. It's likely going to be quite some time until a new language version will happen, still making the task unnecessary difficult is not a good idea. > It seems that there is very little work going on at the > moment to expand the syntax. That speaks loads about the > excellent quality of the current syntax and code, since > it is clearly being used widely. > I can only speak for myself, but the reason for very little going on is totally to blame on lack of spare time. Also there's always the concern of breaking scripts, so syntax changes are slower than other changes. > This is only for the sake of making it easy to download > an compile reliably. I am unfamiliar with github and the > ethics of cooperation on the open source site, so forgive > me and inform me if this is the wrong approach to getting > new code into the world and tested. > Working from github certainly makes things easier, I'll try to build some special Windows snapshots for people who just want to give it a try. Might take a couple of days though... If you want to chat a bit more interactively, you can find Marius (nickname kintel) and me (nickname teepee) quite often in the #openscad IRC channel on freenode. Just say hello and hang around a bit, someone will notice eventually. http://webchat.freenode.net/?channels=openscad Small note on git/github usage, it will probably help to work on changes in a separate branch instead of directly using master. It's usually better to merge things in smaller changes that belong to a single topic (via pull requests). If everything is just committed to master, it's much more complicated as everything is mixed together. > Who else is working on the OpenScad C++/parser code here > and what are they doing? > I'm not aware of bigger changes going on in the parser, I think the latest bigger change was about better line number tracking and that is in master now. ciao, Torsten.

RU

Richard Urwin

Mon, Oct 17, 2016 11:47 PM

ottojas wrote

I have forked/cloned the openscad system to a new repository at:

https://github.com/ottojas/openscad

This is only for the sake of making it easy to download an compile
reliably. I am unfamiliar with github and the ethics of cooperation on
the open source site, so forgive me and inform me if this is the wrong
approach to getting new code into the world and tested.

For what it is worth, I wrote an article on this sort of stuff, the
technicalities not the ethics, a while back. More so I didn't forget than
anything else but it may be helpful.

http://www.soronlin.org.uk/github-setup

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

ottojas wrote > I have forked/cloned the openscad system to a new repository at: > > https://github.com/ottojas/openscad > > This is only for the sake of making it easy to download an compile > reliably. I am unfamiliar with github and the ethics of cooperation on > the open source site, so forgive me and inform me if this is the wrong > approach to getting new code into the world and tested. For what it is worth, I wrote an article on this sort of stuff, the technicalities not the ethics, a while back. More so I didn't forget than anything else but it may be helpful. http://www.soronlin.org.uk/github-setup -- View this message in context: http://forum.openscad.org/Convert-from-object-to-polygon-polyhedron-tp18522p18760.html Sent from the OpenSCAD mailing list archive at Nabble.com.

O

otto

Tue, Oct 18, 2016 5:37 AM

Thanks for kind words and encouragement.

RE:

Also there's always the concern of breaking scripts, so
syntax changes are slower than other changes.

The changes are small.

I am nearly sure all old scripts will work with this syntax addition.
On the other hand, until it has been further tested, I am very shy about
guaranteeing the code will work everywhere.

Regards
Otto

On Mon, 17 Oct 2016 23:56:04 +0200
Torsten Paul Torsten.Paul@gmx.de wrote: