Hello,
I have been reading, documenting, doing research and speaking with OpenSCAD
mentors a lot these days and I've managed to come up with following
solutions and conclusions regarding the OpenSCAD Importer project :
1) The idea of using the FreeCAD LGPL python parser and implementing it
into BRL-CAD code base is a *no-go*. It would imply using the python code
already existent for parse() and writing another python logical component
for creating the evaluation step of the process, the traverser from the AST
tree to .g format and would also be something hard to integrate in to the
existing conversion toolchain (which is based on C/C++ files). In my
opinion, it doesn't sound right to develop a python evaluator when BRL-CAD
requires python bindings anyway.
2) OpenSCAD has a C++ parser that theoretically can be extracted and used
in a common library. The only problem would be that its dependencies are
huge and it would go way beyond a GSoC project to extract it from the main
codebase. For example, there are about 20-30 classes using that and I would
need to refactor them as well, in a way that a change in OpenSCAD code
wouldn't break the library neither for them, nor for BRL-CAD. This is
possible but, as even a GSoC project alone, it won't bring any immediate
benefit to any of this orgs.
3) Another solution would be to build a slim API on top their dependencies
and have BRL-CAD maintain that as part of OpenSCAD. But for the library to
be used by BRL-CAD it would mean relicensing half of OpenSCAD to BSD/MIT
which is not currently an option for them.
Conclusion: as far as making something usable, integrated, easy to maintain
and valuable for BRL-CAD (and potentially for them too), making it from
scratch, using only existing BRL-CAD tools for help is the best option out
there for this GSoC project.
After reading some more about the lexical and syntactical analysis , about
how a parser is created and implemented and also about the AST tree that is
generated, my plan (as recommended by OpenSCAD community) is to start by
making a C++ importer for *.csg files and then extend it to cover all the
*.scad features. The interesting part would come when I will have to save
the info from the tree to .g format and I hope the BRL-CAD community could
help me with info about the API and the geometry insights. I can research
on my own but it will take considerably longer time.
I will bring the updates needed to my proposal asap and hope for a review
to correct any issues that might appear.
PS: I added a new patch <https://sourceforge.net/p/brlcad/patches/329/> a
few days ago regarding the object oriented approach of my basic importer.
It basically uses an object to takes care of the reading and writing from
the input to the output. I would really appreciate your opinion on that, as
well as a review/feedback on my (new/old) proposal.
Regards,
Andrei
On Fri, Mar 20, 2015 at 11:59 PM, Christopher Sean Morrison <brl...@mac.com>
wrote:
>
> On Mar 19, 2015, at 7:33 PM, Ilinca Andrei <andrei.ilinc...@gmail.com>
> wrote:
>
> Kintel advised me to aim towards creating a common parser for both
> openscad and brl-cad and relicense that as LGPL or BSD/MIT. He said we
> could either refactor existing openscad code into a clean component, or
> rewrite the parser and retrofit it into openscad. The former is a bit messy
> but safer - the latter would be preferable but is likely a fair bit of
> work. What is your advice regarding this matter?
>
>
> We would prefer bsd/mit license, but as far as which approach would be
> better — that’s not something I can fully answer without researching the
> situation in depth. All I can offer is industry observation. You being
> unfamiliar with the existing code will undoubtedly be biased towards a
> rewrite. That’s a position *most* programmers prefer taking when presented
> with a refactor vs rewrite. However, most research on the subject has
> shown it’s nearly always better to refactor. Exceptions are when you’re
> changing entire paradigms, sometimes when you’re changing languages, or
> when it’s just not very much or the code is young. The bigger and more
> mature the code, the less likely it’ll be cost effective.
>
> That said, I know very little about the modular status of their code, its
> age/maturity, its complexity, or the level of effort that might be
> involved. Just recognize your own bias when estimating, and if you work
> with them to estimate that effort, you should be able to answer the
> question better than anyone. Summary: break down both those options into a
> set of at least 10 subtasks and estimate how long each might take, show
> them your estimates and see if they concur, then you’ll have a better plan
> on how to proceed.
>
> I understood a bit more about their internal structure (their compile
> table
> <https://github.com/openscad/openscad/blob/master/doc/OpenSCAD-compile.pdf>
> was very useful too) and there are 2 types of OpenSCAD files: *.scad-
> "normal" ones, providing the full list of features and *.csg , which are a
> subset that only contain a smaller set of features and those are basically
> a tree describing the model using a defined set of operators. So, if for
> the .scad file ,the converting flow would be .scad -> (parse) -> AST ->
> (evaluate) -> Node Tree , for the .csg file that would turn into .csg ->
> (parse) -> Node Tree, leaving out the evaluating part. He said that, if I
> go for the .csg -> .g first, a good way to start would be this
> <https://github.com/FreeCAD/FreeCAD_sf_master/tree/master/src/Mod/OpenSCAD>.
> What is your opinion?
>
>
> I have no basis with their code or that module to have an opinion on
> whether that’s a good way. I’m would have to explore and do extensive
> homework (which you should be doing). Doing .csg to .g first does sound
> intrinsically less risky on the surface simply because there’s not an
> intermediate representation and evaluation step. Incremental steps that
> demonstrate functionality is desirable.
>
> They have also told me about FreeCAD and their python parser. I believe I
> could utilize that python code to quickly establish a .csg to .g converter
> (that might be good for prototyping, testing etc.). The only problem will
> be using it in brl-cad's binary, since brl-cad uses C/C++. A C++ component
> could be build later, separately, but will take longer time. Do you think I
> should start working on it ?
>
>
> We would prefer something that will integrate with our newly developing
> geometry conversion (GCV) API. Binding through to python can work but is
> not ideal (especially for large complex models with lots of detail). If
> you went with a refactoring approach, would that also be python code or
> C/C++ code?
>
> A beneficial aspect for both orgs would be to also make (if time allows) a
> .g -> .scad converter. Kindel suggested that if we successfully develop a
> .scad -> .g one, to reverse the algorithm wouldn't be so hard. I believe
> this would (very probably) overcome the GSoC timeline but I'm willing to
> work until October 1st (when school starts) if needed in order to complete
> both converters. Do you think its a good idea or its too much to ask?
>
>
> Going .g to .scad would be very easy, but I agree that you almost
> certainly will not have time during GSoC to do both (unless you’re just
> that awesome). ;) If and when you start going down that route, we can
> certainly help you navigate the BRL-CAD .g API for creating that exporter.
> We have LOTS of examples you can follow that are very similar to what
> you’ll need.
>
> Cheers!
> Sean
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
