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
> 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. 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
