On Tue, 13 Jul 2010 12:17:12 -0300 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
> On Tue, Jul 13, 2010 at 1:22 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Mon, 12 Jul 2010 21:10:21 -0300 Gustavo Sverzut Barbieri > > <barbi...@profusion.mobi> 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. > 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. > 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. > As an example, in most of other projects people handle this with > external files usually named ".idl", which are processed and generates > the boring C code. WebKit uses that to generate most of javascript > objects, etc. Other examples are gperf, that uses another format for > their description instead of hacking into own c-like, etc. > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
