On Tue, Jul 13, 2010 at 8:52 PM, Carsten Haitzler <raster@...> wrote:
> On Tue, 13 Jul 2010 12:17:12 -0300 Gustavo Sverzut Barbieri
> <barbieri@...> said:
>> On Tue, Jul 13, 2010 at 1:22 AM, Carsten Haitzler <raster@...>
>> > On Mon, 12 Jul 2010 21:10:21 -0300 Gustavo Sverzut Barbieri
>> > <barbieri@...> said:
>> > but geneet requires i define my struct in 1 place, and then separately keep
>> > a geneet description file in sync with that struct. it also doesn't help
>> > solve the "free this for me" code generation too. sure - not a problem in
>> > python, but in c it is. geneet sounds to me like something that only really
>> > benefits python. for c it makes no real big difference. you still now have
>> > 1 place to define struct, 1 to define the edd (be it geneet file or
>> > boilerplate code possibly made shorter with macros) and another to free it.
>> Actually we don't have Python-EET, as EET is useless from Python given
>> it already provide transparent serialization using pickle protocol.
> well then... what leandro said:
> "one input generates source for C, Python, ..." is kind of moot - python is
> useless to mention. as such geneet on;y handles generating a parser for c. so
> talk of other languages is moot. this is one of those "we can talk about it in
> theory until the cows come home, but it's not going to happen. the day it does
> geneet can be split internally into a languages-specific pre-parser that strips
> out geneet commands from src and then the geneet consumer with then a bunch
> of per-langauge parser outputs". as such this is all very academic as the
> shared part will be relatively small compared to all the rest.
The high level description of your data is important, if it is easy
and simple, then better. You can use it to generate documentation
diagrams and so on. Also, if you have different peers using it, like
we do, then it is bad to replicate, you will lack consistency sooner
>> But we could generate the same model in different languages, that's
>> what Leandro said, we can generate SQL databases and like if required,
>> or convert between them, etc. IE: one of our internal projects
>> requires a remote (python+sql) and local (eet) data, we could generate
>> lots of the code based on this description.
> a closer look at geneet shows that at least it's not useful to e, edje, elm or
> anything existign that uses eet to simplify maintenance etc. it's really closer
> to a full "class" code generator. not eet helper. it HAPPENS to work with eet,
> but as such that's an implementation detail. as such it likely doesn't belong
> inside eet. as you say "we use it to work with sql etc." and as such i see this
> out of scope for eet. it's a completely different tool to what i imagined it to
> be. what i imagined was much simpler and more constrained that'd simplify
> existing code and maintenance. geneet would totally rewrite the way config and
> data structs are done as well as the code managing them.
Well, I fail to understand why it is for elm, but for edje it is not
even in the scope, given that the damn thing is a huge dynamic thing,
that will get even more complex when Cedric's add his optimizations to
not rely on a single struct that does it all. For e17 it is feasible,
but that huge struct e_config will be as huge in the description. For
modules it will be useful.
BTW, we could just add the concept of version to geneet and have it to
check for updates automatically, but so far it is easy to do that
yourself in the user code, deleting or migrating data as desired, as
well as informing the user using some UI element.
>> The free this for me can happen for what is described, you can also
>> asks for callbacks to be defined in user code, like "my_data" ->
>> "my_data_free()" calls "my_data_free_user()" function, that is defined
>> by user. The generated C source can be included our even linked,
>> depending on what you wish.
>> And you don't/shouldn't have to touch the generated files, they are
>> declared as BUILT_SOURCES in automake.
>> > so... as a tool its usefulness just became rather moot for eet itself as it
>> > has no use for the api that eet itself offers (a c/c++ api). if you stick
>> > this in the python bindings for eet - sure. it has a use there.
>> there are and likely there will not be any python-eet.
>> I don't see how define this in a C header would be better. Okay, in
>> theory you don't need to learn the syntax, but you need to learn the
>> syntax in the comments. And you have lots of possible errors to handle
>> you'd not have in the other, like nested structs, possible macros,
>> typedefs, ...
> all would work with what i described. but see above. geneet doesnt simply
> provide helpers for setting up the codec. it becomes a replacement for c data
> structs and their delcaration etc.
I fail to get your point. To me seems just like "I know C syntax and
that's all I want to know", nothing that really matters other than
pure syntax sugar. Dunno, maybe someone that likes to suffer with
parsing can do that and make you happy later, given the information
the generator should work the same
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
Mobile: +55 (19) 9225-2202