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

Reply via email to