api in json format
I kind of getting lost about what you said. But, that's ok.
Don't know if this is helpful but I've been using type inspection, type
casting etc in my lib for quite a while:
type ( x )=str ( tested:18 ) (mode:12)
| 0> type([2, 3])= "arr"
| 1> type([])= "arr"
| 2> type(-4)= "int"
| 3> type(0)= "int"
| 4> type(0.3)= "float"
| 5> type(-0.3)= "float"
| 6> type(2e-6)= "float"
| 7> type(2e3)= "int"
| 8> type(2e-06)= "float"
| 9> type(2e+03)= "int"
| 10> type("a")= "str"
| 11> type("10")= "str"
| 12> type(true)= "bool"
| 13> type(false)= "bool"
| 14> type([1:2:10])= "range" // New 2015.9.10
| 15> type([1:1.5:10])= "range" // New 2015.9.10
| 16> type(undef)= undef
| 17> type(12345678901234500)= "int" // Bugfix 2015.11.17
The type-checking has been a very crucial part of my lib, even geometric
stuff like points, lines and planes can be type-checked:
gtype ( x,dim=3 ) =str ( tested:9 ) (mode:12)
| 0> gtype(P)= "pt"
| 1> gtype([P,Q])= "ln"
| 2> gtype([P,Q,R])= "pl"
| 3> gtype("a")= undef
| 4> gtype([P,Q,R,P])= undef
| 5> gtype([[P,Q],1])= "cir"
| 6> gtype([2,[P,Q]])= "cir"
| 7> gtype([P,1])= "ball"
| 8> gtype([0.5,P])= "ball"
$ Runsun Pan, PhD
$ libs:
doctest ,
faces ( git ),
offline doc ( git ),
runscad.py( 1 , 2 , git ),
synwrite( 1 , 2 );
$ tips:
hash( 1 , 2 ),
sweep ,
var( 1 , 2 ),
lerp ,
animGif ,
precision( 1 , 2 ),
xl-control
--
View this message in context: http://forum.openscad.org/api-in-json-format-tp15418p15473.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 01/04/2016 03:40 PM, runsun wrote:
That's pretty cool. What is the meaning of
@Parameter([10, 20, 30, 50, 100])
Does it mean only the listed values are allowed ?
Yes, this is basically the basis for modeling the functionality
that the Thingiverse Customizer provides by adding comments to the
scad script.
See the github comment for short example screencasts
https://github.com/openscad/openscad/issues/722#issuecomment-69521189
The meta data definition would allow a long list of other
use-cases, not only the customizer parameter specification.
I've started to collect some of the use cases for different
types of annotations in the wiki:
https://github.com/openscad/openscad/wiki/Meta-Data-Use-Cases
The prototype implementation in branch model-meta-data3 uses
the Java Annotation like syntax as shown above, if it would
make things easier for other cases (e.g. OpenSCAD2) it should
be quite simple to use a different syntax...
ciao,
Torsten.
On 01/04/2016 06:49 AM, Neon22 wrote:
maybe module foo() "doc string" {
};
Doug - what do you think is right thing to do for openSCAD2 ?
I think that would be possible with current OpenSCAD too, it
would simply require all new code that uses it to use the new
OpenSCAD version - which is pretty normal.
It seems to be some kind of convention to use triple " to mark
the docstring, so maybe that would make sense here too.
I guess the idea with that is to allow various markup in that
section, including the use of normal single quotes.
Although for current OpenSCAD, that would probably just allow
the syntax as we have no way for introspection or setting some
object field to make it available at runtime (some simple
solution like a docstring() function returning the doc of the
current module could be added, but I'm not sure that's very
useful).
It still would define a standard way for adding documentation,
which is a good thing to have. It might even allow to use
documentation generation tools like Sphinx to run on OpenSCAD
code.
ciao,
Torsten.
Hi Torsten.
Sphinx is specifically designed for Python, so it requires the python """
string literal syntax, as you have noted. We'd have to extend the OpenSCAD
syntax to make it Sphinx compatible.
Or we could use Doxygen, which should work with OpenSCAD right now, with no
language extensions, since Doxygen was designed for C++, and embeds
documentation in C++ comments, which comment syntax is also supported by
OpenSCAD.
Sphinx uses ReStructuredText as its text markup language: RST is mostly
only used by the Python community. Doxygen uses MarkDown, which will be
familiar to a lot of OpenSCAD developers since github also uses MarkDown.
In fact, Doxygen will even process the README.md file at the root of your
project tree, which is also processed by github.
So I think doxygen is a better starting point for an OpenSCAD inline
documentation tool.
On 4 January 2016 at 11:25, Torsten Paul Torsten.Paul@gmx.de wrote:
On 01/04/2016 06:49 AM, Neon22 wrote:
maybe module foo() "doc string" {
};
Doug - what do you think is right thing to do for openSCAD2 ?
I think that would be possible with current OpenSCAD too, it
would simply require all new code that uses it to use the new
OpenSCAD version - which is pretty normal.
It seems to be some kind of convention to use triple " to mark
the docstring, so maybe that would make sense here too.
I guess the idea with that is to allow various markup in that
section, including the use of normal single quotes.
Although for current OpenSCAD, that would probably just allow
the syntax as we have no way for introspection or setting some
object field to make it available at runtime (some simple
solution like a docstring() function returning the doc of the
current module could be added, but I'm not sure that's very
useful).
It still would define a standard way for adding documentation,
which is a good thing to have. It might even allow to use
documentation generation tools like Sphinx to run on OpenSCAD
code.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 01/04/2016 08:00 PM, doug moen wrote:
Sphinx is specifically designed for Python, so it requires the
python """ string literal syntax, as you have noted. We'd have
to extend the OpenSCAD syntax to make it Sphinx compatible.
Yes, it might need extensions, it's not just for Python though.
The Website claims: "...but C/C++ is already supported as well,
and it is planned to add special support for other languages as
well." so it might not be too complicated to have it handle
OpenSCAD as well.
But yes, it's just an example. If there's a different tool that
maybe just needs some configuration or so, that's perfect.
So I think doxygen is a better starting point for an OpenSCAD
inline documentation tool.
Cool, why not. I guess MarkDown is a good option. I don't like
that it's not going to be standardized, but it's wide adoption
still makes it a sensible choice.
ciao,
Torsten.
I know the Sphinx documentation claims C++ support, but this is done by
invoking Doxygen via Breathe. http://breathe.readthedocs.org/en/latest/
On 4 January 2016 at 14:19, Torsten Paul Torsten.Paul@gmx.de wrote:
On 01/04/2016 08:00 PM, doug moen wrote:
Sphinx is specifically designed for Python, so it requires the
python """ string literal syntax, as you have noted. We'd have
to extend the OpenSCAD syntax to make it Sphinx compatible.
Yes, it might need extensions, it's not just for Python though.
The Website claims: "...but C/C++ is already supported as well,
and it is planned to add special support for other languages as
well." so it might not be too complicated to have it handle
OpenSCAD as well.
But yes, it's just an example. If there's a different tool that
maybe just needs some configuration or so, that's perfect.
So I think doxygen is a better starting point for an OpenSCAD
inline documentation tool.
Cool, why not. I guess MarkDown is a good option. I don't like
that it's not going to be standardized, but it's wide adoption
still makes it a sensible choice.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org