On Tue, Jul 13, 2010 at 8:52 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > 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.
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 BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ 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
