On Wed, 14 Jul 2010 12:00:11 -0300 Gustavo Sverzut Barbieri <[email protected]> said:
> On Tue, Jul 13, 2010 at 8:52 PM, Carsten Haitzler <[email protected]> > wrote: > > On Tue, 13 Jul 2010 12:17:12 -0300 Gustavo Sverzut Barbieri > > <[email protected]> said: > > > >> On Tue, Jul 13, 2010 at 1:22 AM, Carsten Haitzler <[email protected]> > >> wrote: > >> > On Mon, 12 Jul 2010 21:10:21 -0300 Gustavo Sverzut Barbieri > >> > <[email protected]> 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 > or later. > > > >> 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 read the above. geneet is not an eet tool. it is only tangentially related to eet as a bi-product of the code generation it does. as you said. it's meant for other languages. it is not an eet tool. it is a code generation tool. it doesnt just generate the eet data descriptor blobs. it generates an entire "class" with api getter/setters. you cannot use it with existing eet using code. you need to totally migrate to its world and its class generation. that makes this out of scope for eet. it's a different tool. it belongs in some group of code-generation tools that are related to efl. it does not belong in eet's package/tree. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
