Hi, "xarĂ¡", :-) I'm feeling some difficulties to translate all those macro code in my mind. I'm wondering if it would be possible to implement this idea with ordinary functions. But I promise to do my best to get in the mood to understand the new approach, as you had done to understand my esperanto-code before, ok? ;-)
2013/8/1 Felipe Sanches <[email protected]> > Good to hear from you again, Felipe! > > I'd like to clarify the reason for the macros and spec file. I've > introduced these as a major refactoring to the codebase, which I think was > my major contribution to LibreDWG. > > The idea is that the file format is declared only once in the spec file, > so that we avoid the duplicate-effort of implementing both the read and the > write routines for the same datastructures. So, the overal file format is > described only once, and read-specific or write-specific macros will > convert the spec into C code for eighter reading or writing the file format. > > happy hacking, > Felipe Sanches > > > On Thu, Aug 1, 2013 at 2:56 PM, Felipe Castro <[email protected]> wrote: > >> Hello, >> >> It's nice to see that people keep working on this stuff. I'm having a bit >> of time to dive into libredwg in these next few months, and I'd like to >> offer some help in order to reach a first release, 0.4 version for example. >> >> When I started that libDWG project alone, I didn't hope to attract much >> interest with other collaborators, mainly because of the Esperanto stuff in >> there. For me it is really very pleasant to work with that language, but I >> know it does not have so much appeal for other programmers in general. And >> digging in the last git code of LibreDWG, I see some "esperantissues" lying >> around... So I may help to finish the code translation to English, as a >> starting point. :-) >> >> What would be the main goal for version 0.4? Isn't it to get a working >> and useful reading library for the early versions (R13, R14, R2000, R2004)? >> If it is working, why not to release just like that, an alpha version? >> >> Next step, try to work out the writing capability? >> >> Next one, work on further versions (R2007, and so on)? >> >> I'm trying to understand the changes in the "refactoring" branch. I think >> it's mainly a matter of splitting the code in some smaller files. More >> include files to worry about, maybe it's worthwhile, if it brings more >> organization. The doxygen stuff is cool also. >> >> The API is a really huge work, and it could start with very simple >> things, because there are functions there that maybe would never be used in >> a simple CAD environment. But it doesn't hurt anyway to have access on >> every little peace of Autodesk creativity (handles, for example), that's >> the final goal if you want total control of the file format. Would it be >> useful to follow some DXF references? See: >> http://usa.autodesk.com/adsk/servlet/item?id=12272454&linkID=10809853&siteID=123112 >> >> I don't know what would be the best way to access the API, but I think >> including "api.h" will not be the final result for the library user, rigth? >> Will it be included from the "dwg.h" header? >> >> And the r2007 stuff, I didn't touch it, too much for my brain now... >> >> Another little suggestion, in general: what about turning back to the >> "near side of the moon..."? Some of those MACROS... hum, I don't know, just >> annoying, and those .spec files remember me RedHat... ;-) >> >> Hoping not to hurt hearts with some of my considerations, sincerely yours, >> Felipe Castro. >> > >
