On Mon, Mar 23, 2015 at 5:46 PM, Ilinca Andrei <andrei.ilinc...@gmail.com> wrote: > 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 : > > 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.
I would caution against ruling out all code reuse from OpenSCAD - if there are a few relatively self-contained bits (say, some scad language constructs) that could be isolated and re-used in a new framework, that would still be effort saved. Sometimes you can change the data types in a complex bit of code from theirs to your local versions and save a lot of effort... > 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. I don't know how deep their dependencies are wired in, but remember you don't actually need in this layer any of the code for actual boolean evaluations (for example - I believe they use opencsg for that?). You just need to parse the files and build an in-memory structure. > 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. That's OK as a way to start, especially for the .csg stage, but once you get to the scad language I'd keep an eye open for separable bits that they might be comfortable re-licensing that you could leverage in your new work. > 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. I think starting with the simpler format is a sound idea. Can OpenSCAD "step down" a .scad file to a .csg file as an export option? > 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. Our existing importers should give you a lot of insight into that process - they all have to make the same mappings. We can guide you more specifically if you hit problems, but the the intaval converter (src/conv/intaval) might be a good place to start looking for examples. If I recall, it's got the code broken out into read external format and write .g file parts. Cheers, CY ------------------------------------------------------------------------------ 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
