On Fri, 26 Jul 2013 12:57:24 +0100 Tom Hacohen <tom.haco...@samsung.com> said:
> On 26/07/13 11:23, Carsten Haitzler (The Rasterman) wrote: > > On Fri, 26 Jul 2013 11:26:47 +0200 Raoul Hecky <raoul.he...@gmail.com> said: > > > >> Hi, > >> > >> Le 26.07.2013 01:54, Carsten Haitzler a écrit : > >>> On Thu, 25 Jul 2013 14:58:30 -0300 Gustavo Sverzut Barbieri > >>> <barbi...@profusion.mobi> said: > >>> > >>> On Thu, Jul 25, 2013 at 1:46 PM, Tom Hacohen <tom.haco...@samsung.com> > >>> wrote: > >>>> On 24/07/13 03:09, Carsten Haitzler (The Rasterman) wrote: > >>>>> On Tue, 23 Jul 2013 18:22:02 +0200 Jérémy Zurcher <jer...@asynk.ch> > >>>>> said: > >>>>> > >>>>>> just to clarify a few points: > >>>>>> > >>>>>> - I think the less macro we have in an eo class declaration the best, > >>>>>> actually we have nothing but that extra first parameter called > >>>>>> eo2_o, wich is either an obj_ptr (devs/tasn/eo2) or a call_ctx > >>>>>> (devs/jeyzu/eo2) > >>>>>> > >>>>>> this should go away if we use a stack per thread in eo private > >>>>>> code, so we end up with a clean > >>>>>> EAPI float times(float f, float t); > >>>>>> > >>>>>> - since day 1 break is supported in eo2_do: > >>>>>> #define eo2_do(obj_id, ...) > >>>>>> do > >>>>>> { > >>>>>> obj_ptr_or_ctx = eo2_do_start(obj_id); > >>>>>> if(!obj_ptr_or_ctx) break; > >>>>>> do { __VA_ARGS__ ; } while (0); > >>>>>> eo2_do_end(obj_ptr_or_ctx); > >>>>>> } while (0) > >>>>> > >>>>> i'm worried about people doing return there. seriously - objid came in > >>>>> becau se of experience that people using efl are in general > >>>>> inexperienced programmers who don't take the time to do things right. > >>>>> they do things quickly and take shortcuts, and they ignore warnings. > >>>>> they'd rather patch out abort()s in efl code forcing them to fix their > >>>>> bugs, than fix their bugs. i am fearful that they will stuff in returns > >>>>> quite happily and think it mostly works most of the time... and then > >>>>> find subtle issues and waste our time finding them. > >>>>> > >>>>> how do we protect/stop returns (or goto's for that matter) within the > >>>>> while block. i looked for some pragmas - can't find any to do this. this > >>>>> would be a really useful compiler feature though (to maybe disable some > >>>>> constructs for a sequence of code). > >>>>> > >>>> > >>>> Already showed you a solution, the one with the bla function. It works > >>>> and it's mostly clean. > >>> > >>> > >>> how so? The __VA_ARGS__ may contain a return and it will never reach > >>> eo2_do_end() > >>> > >>> precisely. current eo just can't do it (compiler will barf). if we > >>> could make > >>> the compiler barf... that'd be great! this doesn't work, but if it > >>> could: > >>> > >>> #define eo2_do(obj_id, ...) \ > >>> do { \ > >>> obj_ptr_or_ctx = eo2_do_start(obj_id); \ > >>> if(!obj_ptr_or_ctx) break; \ > >>> do { \ > >>> #define return DONT_USE_RETURN_HERE \ > >>> #define goto DONT_USE_GOTO_HERE \ > >>> __VA_ARGS__ ; \ > >>> #undef return \ > >>> #undef goto \ > >>> } while (0); \ > >>> eo2_do_end(obj_ptr_or_ctx); \ > >>> } while (0) > >>> > >>> then this would be awesome. even if it only worked for gcc (and maybe > >>> clang) as > >>> extensions, i'd be happy enough. some way to disallow it. > >>> > >>> right now, the only thing that comes to mind is the evil "preprocessor > >>> before > >>> cpp". i.e. : > >>> eo_filter file.c | gcc - -o file.o > >>> vs > >>> gcc file.c -o file.o > >>> > >>> and eo_filter is a tool we have to make that can error out and detect > >>> things > >>> like the above... (bonus... it can do other fun things too that cpp/c > >>> can't and > >>> expand code etc.) > >> > >> > >> I did not follow the entire eo/eo2 discussion, but here are some > >> comments on the "eo_filter" > >> thing. > >> Qt uses a similar tool called moc which is a preprocessor (Meta Object > >> Processor) that > >> takes care of handling Qt's C++ extensions (It takes a c++ files and > >> search for the Q_OBJECT > >> macro in class definitions and creates a new c++ file containing the > >> meta-object code for > >> those classes). It let Qt add a lot of different meta programing thing > >> that is not > >> directly available with C++ through the use of specific qt keywords. > >> There is a proof of concept for a rewrite of the moc tool using clang > >> directly to enhance > >> the code parsing and error reporting with all the Qt'ish keywords > >> (slot/signals/...) > >> http://woboq.com/blog/moc-with-clang.html > >> > >> Maybe something similar for eo could be a good solution instead of > >> having a lot of > >> unreadable macros that will always display incomprehensible errors when > >> not used > >> correctly. > >> Having an external preprocessor tool can allow to do thing that are not > >> possible using > >> standard C, and most importantly it can report any wrong usage of eo > >> correctly and > >> display usefull error messages. > >> > >> My 2 cents here ;) > > > > i'm with you. a moc-style preprocessor would cut out a tonne of ugliness and > > arguments and boilerplate fluff. it could warn/error on all the things that > > are wrong AND be portable as all it has to do is read a file, parse and > > output the same text post-parse/expand. > > > > problem is a bunch of people are just dead set against it arguing it > > "creates a new language" "it's not c anymore", etc. etc. and thus we must > > not do it. i personally think these arguments to be academic and purist in > > nature and ultimately just cost us work and pain for nothing but an > > academic argument. > > To be honest, as the biggest objector, I must admit, I'm starting to > agree it might not be that bad of an idea. > > However, I do think that even if we have that, we still need good C API > (we'll have to generate C code anyway), so it's a bit of a futuristic > thing, or at least something that has little to do with the topic at hand. no disagreement on this. we shouldnt make an awful c api and just assume a preprocessor will fix it up. we should make the best "raw c" thing we can, but some things are just a tiny bit beyond the reach of normal c without a little pre-processing. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel