Re: [E-devel] eo and efl
On Tue, 1 Jan 2013 15:02:02 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Mon, 31 Dec 2012 13:46:41 +1000 David Seikel onef...@gmail.com said: On Mon, 31 Dec 2012 10:20:21 +0900 Cedric BAIL cedric.b...@free.fr wrote: On Sun, Dec 30, 2012 at 10:48 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Sun, Dec 30, 2012 at 10:04 AM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Dec 30, 2012 at 12:55 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: snip Bindings: I'm still to see that for real, but IMO it will make bindings worse. Also, people tend to think of bindings as a simply expose C functions in that language 1:1. This is horrible, you're developing for some language and you must cope with that language's style as much as possible. If the work to make the Python or JS bindings were just to generate 1:1, it would be better, but we took the time to think how to match language nicely. This is debatable. I do think that a 1:1 binding is fine as it provide an easy and sure path with time. Still there is clearly a need to implement a layer in the binded language to abstract it and make it feel like a native JS, Python, whatever API. You may not have a 1:1 binding in Elev8, but I think you are doing a higher up layer in JS with EasyUI that could have been an abstraction between a 1:1 binding and the JS world. I also think that this way the binding would have a much easier time to provide a stable API and the script could just include the EasyUI layer they used for development. That one would have worked on every version of the binding without any breakage ever and it would have make the life of maintaining that binding much more easy. For bindings, the worse part here is that you'll never be able to construct va_list then you'll never be abe to expose eo_do() itself. It's not worse, it just limiting and sad. You will be limited to use only one function call even when you have all the value needed to do much more... I also would have liked a way to bind that. Then it's like fixing a problem that is not broken. Seriously ? Our binding are massively behind. We have barely one maintained binding, JS and a few other that are slowly dying. If half of our API was present in them, I would be happy, but that's far from being the case. So what is the status of the Perl, Python, Ruby, Go and all other bindings ? Tell me they are all great, cover 80% of our API (I am not even asking for 100%) and well maintained. The Lua bindings are great, well maintained, but only cover a small percentage of EFL API. They also try to leverage Lua ways of doing stuff to make it easy for Lua scripters, it's not exactly a 1:1 binding. It's close to 1:1 though. It's not slowly dying. :-P I would love to resurrect my ancient RAD tool and have some higher level stuff for edje Lua, but I suspect Raster would veto that. I'm not ready to do that yet anyway, so will leave that for a later discussion. The textblock API is kinda scary huge, that's why I left it out last time I was adding Lua bindings. Which bit me last week when I was considering a design that would use textblock from Lua. lol BTW, no one answered my previous question - will I have to redo the Lua bindings to suit eo now? no. you don't have to. current efl api will keep working fine until 2.0 after then it may continue to work (to greater or lesser extents) but there definitely will bee no support for expansion of it and new stuff will go via eo. i'd say it's early days for eo so you may end up with teething problems if you try to move to it, BUT, it may also save you a buttload of time in the long-run due to introspection etc. I also wanted to try out the LuaJIT C binding stuff. So I think I might experiment with them both, see what pans out the best. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Tue, 1 Jan 2013 16:30:21 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Tue, 1 Jan 2013 15:16:13 +0900 Jérôme Pinot ngc...@gmail.com said: On 01/01/13 15:02, Carsten Haitzler wrote: [snip] but there definitely will bee no support for expansion of it This stings, really. no one said 2.0 is happening soon. it's a long ways off yet. my intent is to have 1.x for at lest 5 years from 1.0. gustavo pushed for 2.0 asap. break early, break often. i disagree. eo is a path TO 2.0 i guess and it slides in early and gives us a long time to beat things into shape. So that will be 1.x for at least five years, meaning we start 2.0 in 2018, with 18 years of development (since 0.17 took 17 years, I figured 0.18 will take 18). That means a release date in 2036? Lets allow a couple of years for safety, and we can have the next major release on 19 January 2038, the nearest major End of The World. B-) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Tue, 1 Jan 2013 16:34:57 +0900 Jérôme Pinot ngc...@gmail.com said: On 01/01/13 16:30, Carsten Haitzler wrote: On Tue, 1 Jan 2013 15:16:13 +0900 Jérôme Pinot ngc...@gmail.com said: On 01/01/13 15:02, Carsten Haitzler wrote: [snip] but there definitely will bee no support for expansion of it This stings, really. no one said 2.0 is happening soon. it's a long ways off yet. my intent is to have 1.x for at lest 5 years from 1.0. gustavo pushed for 2.0 asap. break early, break often. i disagree. eo is a path TO 2.0 i guess and it slides in early and gives us a long time to beat things into shape. bee, stings, humour h bee... hahahahaha sorry - missed that reference. :) get it now :) Just thought this endless thread was going too much serious /o\ -- Jérôme Pinot http://ngc891.blogdns.net/ -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Tue, 1 Jan 2013 18:21:14 +1000 David Seikel onef...@gmail.com said: On Tue, 1 Jan 2013 16:30:21 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Tue, 1 Jan 2013 15:16:13 +0900 Jérôme Pinot ngc...@gmail.com said: On 01/01/13 15:02, Carsten Haitzler wrote: [snip] but there definitely will bee no support for expansion of it This stings, really. no one said 2.0 is happening soon. it's a long ways off yet. my intent is to have 1.x for at lest 5 years from 1.0. gustavo pushed for 2.0 asap. break early, break often. i disagree. eo is a path TO 2.0 i guess and it slides in early and gives us a long time to beat things into shape. So that will be 1.x for at least five years, meaning we start 2.0 in 2018, with 18 years of development (since 0.17 took 17 years, I figured 0.18 will take 18). That means a release date in 2036? Lets allow a couple of years for safety, and we can have the next major release on 19 January 2038, the nearest major End of The World. B-) 8-P :) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Monday 31 December 2012 10:20, Cedric BAIL wrote : On Sun, Dec 30, 2012 at 10:48 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Sun, Dec 30, 2012 at 10:04 AM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Dec 30, 2012 at 12:55 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: I don't want to be the boring guy complaining on this. But I can't agree neither on the reasons why this went in, nor how it went in. For me eo is just raping C and all the problems pointed out should be fixed elsewhere. Please describe how. For example how do you plan to link cleanly any object from ecore or eio for example with any evas_object ? How do you plan to give memory compaction ? How do you see we could do the ID indirection ? How can we do a live debug of live object in a program ? How do you provide multiple inheritance ? How do you provide API and ABI stability over time ? How do you make bindings easier to keep in sync possible ? Please share your idea. If you dislike Eo so much, you must have an alternative in mind that solve the same issue that Eo solve. At the moment, I only see rants and no care about the problem that Eo address and the answer we have been giving here. I was trying to stay out of this thread, everybody knows I hate Eo and was against this since the beginning, showing facts on problems it caused to debug. But with these arguments, you're being too naive an eo is the solution for everything is not working. the memory compaction, for example, is independent and either you found out the light that nobody else did, or you'll face huge problems if you try. Not everywhere uses eo_data_get(), then if you replace the memory with some other address underneath, you'll end with lost pointers, garbage and it will be super-hard to find. The change will not be doable in the code base of our size. If may have worked if we started coding like that from day0. Indeed the eo_data_get doesn't allow that. I have been working on a proposal to solve that problem and open some more possibility. I planned to write a mail later this week. Anyway the idea is to move to an api like a rw mutex. So that as long as you hold a pointer to it, it wont get compacted. Main target are currently Evas and Edje where it would help and the code affected is not that big (basically mostly in canvas/ subdirectory). ID indirection helps what? making debug harder? You get an assert as soon as you use or reuse a wrong pointer. Instant backtrace that point to the source of the problem. Zero delay. No hiding. It will help application developers that tend to still manipulate dead object. ABI/API stability is worse, not better. You still have the same problems you had before, but the existing tools to check that (nm + shell scripts to compare 2 libs) won't work... and the worse part is simple: before you could reorder the functions around, now you must keep them in order as they imply an ID and it can't change. Okay, this is very minimum, but it is worse, not better in that regard. nm + shell is a very limited tool to check for API/ABI stability. It completely ignore structure and enum. So it's worse but anyway relying on nm + shell for doing an automated test here, is really a wrong argument. If you want this kind of tool, you will need to move to a llvm/clang's plugin anyway and that kind of plugin would be able to check API/ABI stability for EO. See, you can't still change the parameters. You can't change the return type. You can't change the function name. This is not C++, you can change the parameters and return value as long as they remain opaque. As for changing the public name of a function, I don't see how you could still provide an API/ABI compatibility with such a feature. But as we are doing C, API/ABI stability is almost an non issue here compared to other language (which was my main point on that subject). Bindings: I'm still to see that for real, but IMO it will make bindings worse. Also, people tend to think of bindings as a simply expose C functions in that language 1:1. This is horrible, you're developing for some language and you must cope with that language's style as much as possible. If the work to make the Python or JS bindings were just to generate 1:1, it would be better, but we took the time to think how to match language nicely. This is debatable. I do think that a 1:1 binding is fine as it provide an easy and sure path with time. Still there is clearly a need to implement a layer in the binded language to abstract it and make it feel like a native JS, Python, whatever API. You may not have a 1:1 binding in Elev8, but I think you are doing a higher up layer in JS with EasyUI that could have been an abstraction between a 1:1 binding and the JS world. I also think that this way the binding would have a much easier time to provide a stable API and
Re: [E-devel] eo and efl
On Mon, Dec 31, 2012 at 2:15 AM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Dec 31, 2012 at 12:24 PM, Henrique Dante hda...@profusion.mobi wrote: On Sun, Dec 30, 2012 at 9:28 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Dec 30, 2012 at 12:06 AM, Henrique Dante hda...@profusion.mobi wrote: While developing with Eo I also noticed that it breaks cscope usage. Whenever I wanted to jump to the definition of some method call, I reached a macro in the include file instead. Then I had to use the method ID to do a new search, this time not by definition, but by usage in class definitions. It took me time to understand what you mean by definition. My A definition is a declaration that includes the element's content. Your definition is still vague when speaking about macro, prototype and implementation. I'm not a big fan of discussing terminology. My definition is C definition, so we shouldn't be discussing this. understanding of your complaint is that you don't like virtual. cscope The way you are saying suggests that I don't like some part of object orientation, which is false. I was strictly referring to the implementation of Eo and its influence on development. will never be able to find the implementation (for me definition is Method calls that were not polymorphic, from concrete classes, were made polymorphic with Eo. And in this case, polymorphic means explicitly referenced by an ID. That's the virtual I didn't like. But even if I liked it, it would have broken jump-to-definition the same way. Jump to declaration is not broken and provide documentation, prototype Correct, but it jumps to the abstract (base) declaration, not to the derived one, even with a bottom level object with its own implementation. for said call. That what developer using EFL are looking for. The problem you mentioned was restricted to a (small ?) subset of methods, the ones derived from base classes. Now the whole libraries have this problem. the prototype, that's why I was confused) at compile time, because it That's a declaration. is determined at runtime. The same problem exist with C++ and people No idea how that's done in C++. I think cscope works with C++ by luck. However in an OO language, a method call bound to a concrete, bottom-of-hierarchy, instanced object should be enough to jump to its definition, at compile time, even if the method is virtual (this should only be harder if it's necessary to walk through the object hierarchy). Anyway, jumping to definition of a virtual method with cscope on a C++ project can be done with 1 search, not 2. So now, I don't follow you anymore. Jumping to the prototype of a virtual in C++ work exactly the same way it work in C. At least from an user of the API. I think I now do understand what you mean. You are doing development inside EFL and try to find the macro that correspond to a function implementation, right ? Yes, I was not worried about the prototype, I needed the implementation. As a matter of fixing that issue, couldn't you not instruct csope to do the double jump for you ? It doesn't sounds like the problem is more a limitation in your tool than a real issue. I'd do a script for that, or more probably, will avoid reading the code. think that virtual is useful somehow. Not sure why you're talking about the concept of virtual. My comment was about noticing that developers might avoid EFL because Eo (not OO) has negative effects on development. Maybe because your explanation is confusing. I was supposing you were writing application with EFL and did use the EO API and where complaining about that. Now I think you are trying to work inside EFL with EO API and are complaining about some limitation of your tool. To make things simpler, ignore my second paragraph. I explicitly stated that this was something I also noticed, but you ignored the first paragraph and focused in trying solve my specific problem, instead. Even if you convinced me that what's broken are my tools, this is not about me. In fact we need virtual today in EFL for at least to case, for at least to case that I know of. First geometry get on Evas_Object_Text and second for all the *_file_set that lurk around, have the same prototype and do the almost the same think, but just exist to confuse the developer. That looks like there are too few cases to consider it as a benefit. That's just the two first example that came to me without having the need to search for anything. I am sure there is more. Making a non virtual and virtual function call would have added a layer of complexity and risk for API/ABI break later. It's a trade-of . Repeating again, I sent the comment to sugest that Eo could have a negative acceptance by developers. It was difficult to understand the context of your remark. Now, I think you are trying to get used to EFL source code and Eo is another bit of complexity in that
Re: [E-devel] eo and efl
On Mon, Dec 31, 2012 at 2:20 AM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Dec 30, 2012 at 10:48 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Sun, Dec 30, 2012 at 10:04 AM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Dec 30, 2012 at 12:55 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: I don't want to be the boring guy complaining on this. But I can't agree neither on the reasons why this went in, nor how it went in. For me eo is just raping C and all the problems pointed out should be fixed elsewhere. Please describe how. For example how do you plan to link cleanly any object from ecore or eio for example with any evas_object ? How do you plan to give memory compaction ? How do you see we could do the ID indirection ? How can we do a live debug of live object in a program ? How do you provide multiple inheritance ? How do you provide API and ABI stability over time ? How do you make bindings easier to keep in sync possible ? Please share your idea. If you dislike Eo so much, you must have an alternative in mind that solve the same issue that Eo solve. At the moment, I only see rants and no care about the problem that Eo address and the answer we have been giving here. I was trying to stay out of this thread, everybody knows I hate Eo and was against this since the beginning, showing facts on problems it caused to debug. But with these arguments, you're being too naive an eo is the solution for everything is not working. the memory compaction, for example, is independent and either you found out the light that nobody else did, or you'll face huge problems if you try. Not everywhere uses eo_data_get(), then if you replace the memory with some other address underneath, you'll end with lost pointers, garbage and it will be super-hard to find. The change will not be doable in the code base of our size. If may have worked if we started coding like that from day0. Indeed the eo_data_get doesn't allow that. I have been working on a proposal to solve that problem and open some more possibility. I planned to write a mail later this week. Anyway the idea is to move to an api like a rw mutex. So that as long as you hold a pointer to it, it wont get compacted. Main target are currently Evas and Edje where it would help and the code affected is not that big (basically mostly in canvas/ subdirectory). ID indirection helps what? making debug harder? You get an assert as soon as you use or reuse a wrong pointer. Instant backtrace that point to the source of the problem. Zero delay. No hiding. It will help application developers that tend to still manipulate dead object. ABI/API stability is worse, not better. You still have the same problems you had before, but the existing tools to check that (nm + shell scripts to compare 2 libs) won't work... and the worse part is simple: before you could reorder the functions around, now you must keep them in order as they imply an ID and it can't change. Okay, this is very minimum, but it is worse, not better in that regard. nm + shell is a very limited tool to check for API/ABI stability. It completely ignore structure and enum. So it's worse but anyway relying on nm + shell for doing an automated test here, is really a wrong argument. If you want this kind of tool, you will need to move to a llvm/clang's plugin anyway and that kind of plugin would be able to check API/ABI stability for EO. See, you can't still change the parameters. You can't change the return type. You can't change the function name. This is not C++, you can change the parameters and return value as long as they remain opaque. As for changing the public name of a function, I don't see how you could still provide an API/ABI compatibility with such a feature. But as we are doing C, API/ABI stability is almost an non issue here compared to other language (which was my main point on that subject). Bindings: I'm still to see that for real, but IMO it will make bindings worse. Also, people tend to think of bindings as a simply expose C functions in that language 1:1. This is horrible, you're developing for some language and you must cope with that language's style as much as possible. If the work to make the Python or JS bindings were just to generate 1:1, it would be better, but we took the time to think how to match language nicely. This is debatable. I do think that a 1:1 binding is fine as it provide an easy and sure path with time. Still there is clearly a need to implement a layer in the binded language to abstract it and make it feel like a native JS, Python, whatever API. You may not have a 1:1 binding in Elev8, but I think you are doing a higher up layer in JS with EasyUI that could have been an abstraction between a 1:1 binding and the JS world. I also think that this way the binding would have a much easier time to provide a
Re: [E-devel] eo and efl
On Sun, Dec 30, 2012 at 11:33 PM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Dec 2012 14:19:01 -0200 Lucas De Marchi lucas.demar...@profusion.mobi said: On Sun, Dec 30, 2012 at 12:51 PM, Carsten Haitzler ras...@rasterman.com wrote: i shall start with a single one: 'Subject: [E-devel] Eobj - Request for review/comments' in april 2012. indeed I missed that. But don't be that silly. Let me explain: wait. you challenge me to provie even 1 example (there's more) and now you dismiss it by saying don't be silly? this line of logic i fail to follow. It's the same logic Mike applied. That was not a RFC: generalizing all objects with a single one I just added a project under PROTO/ named ldm with features X, Y and Z. Will you review it? probably not. if you said we want to make this the future of all oo infra in efl and asked for input, i would. 5 month later later I come back and replace all your Eo structs underneath you with my ldm structs, because this is the way I think is the right way. Will you complain? Of course you will. that is nothing like what happened. not even close. you have many opportunities to have input, comment etc. To worse, it was added together with the move of the tree to efl/. And I *DID* complain saying there was no reason to rush eobj in. Of course you didn't hear because a patch like eobj would be impossible to maintain out of tree. indeed it would be impossible - saying i didn't listen is just your way of saying you disagreed therefore i will say you didn't listen. you even provide a justification for disagreing here, and yet... you decide it's not listening. for me not listening is the same as disagreeing here. what i see here is there is a change, and i don't like change. i hate change. change means i have to adapt and i hate doing that. oh, who is clueless now? I am the changer guy. I love changes. The good ones, not just because we can. i suggest we roll back the async rendering code in evas. it's change. it creates problems. it hasn't solved anything. oh - and edbus. it's change. it's created leaks and crashes and soaked up my time during my vacation. let's roll it back. i hate change. I am impressed by your lack of arguments now bringing up this. don't be silly. this is EXACTLY what you sound like. you'd now just pulling justifications out of the air to back a desire for no change. I said don't be silly because you are twisting the words and facts to justify adding eo. And as others pointed out, saying this has been discussed on IRC and mailing list and interpreting that like it has been decided to do this way is just silly. there were 2 main lines of how to solve our oo stuff. gustavo's which was just use smart objects which i said wouldn't fly because we can't make lower level objects use this (timers etc). they are also too heavy-weight for such uses even if we twisted the world. evas canvases then can't ve objects either. they also do not support multiple inheritance (or multiple interfaces) which i listed as a requirement because elm was literally creating objects that did this (scrolled entry for example). i had requirements that went roughly like this: 1. support normal single inheritance 2. multiple inheritance must work sensibly 3. we have to be able to go down to ecore and make timers etc. into objects 4. we have to be able to attach objects to eachother weakly or tightly (weak refs or strong refs) 5. we need to clean up our callback prototype mess and unify 6. we need to make object ptr (handle) access much safer in the event of freed objects or errant (garbage) pointers as well as typechecks 7. since #6 probably is going to raise object access overhead, some way of alleviating this would be really nice 8. we have to be able to slide it under our current api/abi so stuff keeps working as it used to but in future we can migrate to it once slide underneath everywhere 9. support runtime method overriding etc. 10. unify the data attaching we have (evas_object_data_set/get/del) 11. allow for memory compaction/gc to alleviate fragmentation i think i had a few more. some were more important that others, but multiple-inheritance was a big one as it was problematic with just stuffing struct in struct methods of single inheritance gobject did. oh... now I see one of the reasons why I don't like it... it's gobject on steroids. eo wasn't even created yet. there were toy attempts/exampels in different forms etc. to explore ideas and see what would work or not but nothing concrete. this was the time to have a say. even with the first iterations of eo - it was the time to have a say. eo solves the bove, OR lays the groundwork to be able to solve the above transparently under the hood in future. now you claim eo adds all sorts of problems. the eo_do() is impractical. i just don't get that. it's just as practical as now. obj =
Re: [E-devel] eo and efl
On Mon, 31 Dec 2012 18:18:10 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: On Sun, Dec 30, 2012 at 11:33 PM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Dec 2012 14:19:01 -0200 Lucas De Marchi lucas.demar...@profusion.mobi said: On Sun, Dec 30, 2012 at 12:51 PM, Carsten Haitzler ras...@rasterman.com wrote: i shall start with a single one: 'Subject: [E-devel] Eobj - Request for review/comments' in april 2012. indeed I missed that. But don't be that silly. Let me explain: wait. you challenge me to provie even 1 example (there's more) and now you dismiss it by saying don't be silly? this line of logic i fail to follow. It's the same logic Mike applied. That was not a RFC: generalizing all objects with a single one First RFC = Request For Comments, so that part was in there. Second, traditionally a RFC is about a specific implementation. It's up to the objectors to supply the comments that was requested, in a timely fashion, otherwise the proposer wont know there's any objections. Quibbling over the exact title now instead of making comments at the time is just silly. Here in EFL we have other traditions to, one is to rewrite stuff. I've had stuff rewritten out from under me when it was still being developed, I don't like the replacement, but seems most others do. I just shut up about it, except for rare snide comments like this one. :-P So if you really don't like it, write a replacement, or shut up. I'm still on the fence about eo, coz I've not had to deal with it much yet. And no one has answered the question I keep asking. lol -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Mon, 31 Dec 2012 13:46:41 +1000 David Seikel onef...@gmail.com said: On Mon, 31 Dec 2012 10:20:21 +0900 Cedric BAIL cedric.b...@free.fr wrote: On Sun, Dec 30, 2012 at 10:48 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Sun, Dec 30, 2012 at 10:04 AM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Dec 30, 2012 at 12:55 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: snip Bindings: I'm still to see that for real, but IMO it will make bindings worse. Also, people tend to think of bindings as a simply expose C functions in that language 1:1. This is horrible, you're developing for some language and you must cope with that language's style as much as possible. If the work to make the Python or JS bindings were just to generate 1:1, it would be better, but we took the time to think how to match language nicely. This is debatable. I do think that a 1:1 binding is fine as it provide an easy and sure path with time. Still there is clearly a need to implement a layer in the binded language to abstract it and make it feel like a native JS, Python, whatever API. You may not have a 1:1 binding in Elev8, but I think you are doing a higher up layer in JS with EasyUI that could have been an abstraction between a 1:1 binding and the JS world. I also think that this way the binding would have a much easier time to provide a stable API and the script could just include the EasyUI layer they used for development. That one would have worked on every version of the binding without any breakage ever and it would have make the life of maintaining that binding much more easy. For bindings, the worse part here is that you'll never be able to construct va_list then you'll never be abe to expose eo_do() itself. It's not worse, it just limiting and sad. You will be limited to use only one function call even when you have all the value needed to do much more... I also would have liked a way to bind that. Then it's like fixing a problem that is not broken. Seriously ? Our binding are massively behind. We have barely one maintained binding, JS and a few other that are slowly dying. If half of our API was present in them, I would be happy, but that's far from being the case. So what is the status of the Perl, Python, Ruby, Go and all other bindings ? Tell me they are all great, cover 80% of our API (I am not even asking for 100%) and well maintained. The Lua bindings are great, well maintained, but only cover a small percentage of EFL API. They also try to leverage Lua ways of doing stuff to make it easy for Lua scripters, it's not exactly a 1:1 binding. It's close to 1:1 though. It's not slowly dying. :-P I would love to resurrect my ancient RAD tool and have some higher level stuff for edje Lua, but I suspect Raster would veto that. I'm not ready to do that yet anyway, so will leave that for a later discussion. The textblock API is kinda scary huge, that's why I left it out last time I was adding Lua bindings. Which bit me last week when I was considering a design that would use textblock from Lua. lol BTW, no one answered my previous question - will I have to redo the Lua bindings to suit eo now? no. you don't have to. current efl api will keep working fine until 2.0 after then it may continue to work (to greater or lesser extents) but there definitely will bee no support for expansion of it and new stuff will go via eo. i'd say it's early days for eo so you may end up with teething problems if you try to move to it, BUT, it may also save you a buttload of time in the long-run due to introspection etc. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Mon, 31 Dec 2012 18:18:10 -0200 Lucas De Marchi lucas.demar...@profusion.mobi said: On Sun, Dec 30, 2012 at 11:33 PM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Dec 2012 14:19:01 -0200 Lucas De Marchi lucas.demar...@profusion.mobi said: On Sun, Dec 30, 2012 at 12:51 PM, Carsten Haitzler ras...@rasterman.com wrote: i shall start with a single one: 'Subject: [E-devel] Eobj - Request for review/comments' in april 2012. indeed I missed that. But don't be that silly. Let me explain: wait. you challenge me to provie even 1 example (there's more) and now you dismiss it by saying don't be silly? this line of logic i fail to follow. It's the same logic Mike applied. That was not a RFC: generalizing all objects with a single one wth? so now you want to get pedantic with an rfc wording? there are not many of them. comment was asked for long ago now. you chose not to. it's a bit late for the rip it out and don't do it at all point. i'll repeat it here. if there are things to improve and make better in eo - sure. make those points. let's improve it. I just added a project under PROTO/ named ldm with features X, Y and Z. Will you review it? probably not. if you said we want to make this the future of all oo infra in efl and asked for input, i would. 5 month later later I come back and replace all your Eo structs underneath you with my ldm structs, because this is the way I think is the right way. Will you complain? Of course you will. that is nothing like what happened. not even close. you have many opportunities to have input, comment etc. To worse, it was added together with the move of the tree to efl/. And I *DID* complain saying there was no reason to rush eobj in. Of course you didn't hear because a patch like eobj would be impossible to maintain out of tree. indeed it would be impossible - saying i didn't listen is just your way of saying you disagreed therefore i will say you didn't listen. you even provide a justification for disagreing here, and yet... you decide it's not listening. for me not listening is the same as disagreeing here. a very fundamental difference, but that may be lost on you. what i see here is there is a change, and i don't like change. i hate change. change means i have to adapt and i hate doing that. oh, who is clueless now? I am the changer guy. I love changes. The good ones, not just because we can. you only lik the changes you make - as you understand them. others changes are to be debated long after the opportunity for debate is over. i suggest we roll back the async rendering code in evas. it's change. it creates problems. it hasn't solved anything. oh - and edbus. it's change. it's created leaks and crashes and soaked up my time during my vacation. let's roll it back. i hate change. I am impressed by your lack of arguments now bringing up this. i'm continuing from the logic of change is bad so roll it back. most of your complaints are just that. don't be silly. this is EXACTLY what you sound like. you'd now just pulling justifications out of the air to back a desire for no change. I said don't be silly because you are twisting the words and facts to justify adding eo. i listed a long list of things as to why eo fits the bill. i gave a list of things we need. it provides solutions. you do not provide them. And as others pointed out, saying this has been discussed on IRC and mailing list and interpreting that like it has been decided to do this way is just silly. there were 2 main lines of how to solve our oo stuff. gustavo's which was just use smart objects which i said wouldn't fly because we can't make lower level objects use this (timers etc). they are also too heavy-weight for such uses even if we twisted the world. evas canvases then can't ve objects either. they also do not support multiple inheritance (or multiple interfaces) which i listed as a requirement because elm was literally creating objects that did this (scrolled entry for example). i had requirements that went roughly like this: 1. support normal single inheritance 2. multiple inheritance must work sensibly 3. we have to be able to go down to ecore and make timers etc. into objects 4. we have to be able to attach objects to eachother weakly or tightly (weak refs or strong refs) 5. we need to clean up our callback prototype mess and unify 6. we need to make object ptr (handle) access much safer in the event of freed objects or errant (garbage) pointers as well as typechecks 7. since #6 probably is going to raise object access overhead, some way of alleviating this would be really nice 8. we have to be able to slide it under our current api/abi so stuff keeps working as it used to but in future we can migrate to it once slide underneath everywhere 9. support runtime method overriding etc. 10. unify the data attaching we
Re: [E-devel] eo and efl
On 01/01/13 15:02, Carsten Haitzler wrote: [snip] but there definitely will bee no support for expansion of it This stings, really. -- Jérôme Pinot http://ngc891.blogdns.net/ signature.asc Description: Digital signature -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Tue, 1 Jan 2013 15:16:13 +0900 Jérôme Pinot ngc...@gmail.com said: On 01/01/13 15:02, Carsten Haitzler wrote: [snip] but there definitely will bee no support for expansion of it This stings, really. no one said 2.0 is happening soon. it's a long ways off yet. my intent is to have 1.x for at lest 5 years from 1.0. gustavo pushed for 2.0 asap. break early, break often. i disagree. eo is a path TO 2.0 i guess and it slides in early and gives us a long time to beat things into shape. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On 01/01/13 16:30, Carsten Haitzler wrote: On Tue, 1 Jan 2013 15:16:13 +0900 Jérôme Pinot ngc...@gmail.com said: On 01/01/13 15:02, Carsten Haitzler wrote: [snip] but there definitely will bee no support for expansion of it This stings, really. no one said 2.0 is happening soon. it's a long ways off yet. my intent is to have 1.x for at lest 5 years from 1.0. gustavo pushed for 2.0 asap. break early, break often. i disagree. eo is a path TO 2.0 i guess and it slides in early and gives us a long time to beat things into shape. bee, stings, humour Just thought this endless thread was going too much serious /o\ -- Jérôme Pinot http://ngc891.blogdns.net/ signature.asc Description: Digital signature -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Sat, Dec 29, 2012 at 10:32 PM, Carsten Haitzler ras...@rasterman.com wrote: On Sat, 29 Dec 2012 13:06:25 -0200 Henrique Dante hda...@profusion.mobi said: On Sat, Dec 29, 2012 at 12:48 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 28 Dec 2012 22:31:18 + Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Hey! I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. it does make me consider entering one of those code obfuscation contests... - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. backtraces with eo are the reason I don't see myself ever switching to the 1.8 branch. as for benchmarks, I saw some supposed numbers thrown around during early eo development which claimed that it was slower, but not that much slower, and worth it for the gains - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party not to mention the spam just from running e - Despite raster arguing this is not an API break, I strongly believe it is. It broke compilation of lots of c++ applications (I'll not repeat myself here... in the mailing list there are my other arguments why it is an api breakage) My opinion is to revert the whole thing, but I'm sure this would be a major task after the surgery to put it in was made. I'd at least like the people responsible for it to answer the points above, and people who like me think this is all crap to step up and say so. Lucas De Marchi depressing though it may be to think about, I have to agree with your points. I'm not saying it needs to be reverted, but I don't see any benefit to keeping it unless the goal was to reduce my commits to the afflicted areas to near zero. while it's impressive that all of the eo stuff was added with relatively little breakage (as opposed to my expectations), the idea of having to learn what is essentially a different programming language in order to work on efl internals again in trunk is really demotivating. maybe I'll become the kwo of the 1.7 branch? fair enough. it's a change. it's not a change i wanted. it's a change that was NEEDED. needed because once you go beyond the scope of us few efl devs, you hit a wall of developers who can take our api - documented or not, with examples or Hello, from a new developer pespective, I think Eo is creating an unwelcome encapsulation of the API, that's usually neither expected nor wanted in C. It's replacing simple function calls with message building with handles and varargs. The way I see it, new C application developers from the community (as opposed to employees required to work on EFL) which could potentially choose EFL as a toolkit, would avoid it, not be attracted to it. While developing with Eo I also noticed that it breaks cscope usage. Whenever I wanted to jump to the definition of some method call, I reached a macro in the include file instead. Then I had to use the method ID to do a new search, this time not by definition, but by usage in class definitions. The other way doesn't work well either: single stepping in gdb to find out the code path or looking at a backtrace are both polluted with Eo calls. In general single stepping on
Re: [E-devel] eo and efl
On Sun, 30 Dec 2012 09:27:40 -0200 Lucas De Marchi lucas.demar...@profusion.mobi said: On Sat, Dec 29, 2012 at 10:32 PM, Carsten Haitzler ras...@rasterman.com wrote: On Sat, 29 Dec 2012 13:06:25 -0200 Henrique Dante hda...@profusion.mobi said: On Sat, Dec 29, 2012 at 12:48 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 28 Dec 2012 22:31:18 + Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Hey! I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. it does make me consider entering one of those code obfuscation contests... - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. backtraces with eo are the reason I don't see myself ever switching to the 1.8 branch. as for benchmarks, I saw some supposed numbers thrown around during early eo development which claimed that it was slower, but not that much slower, and worth it for the gains - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party not to mention the spam just from running e - Despite raster arguing this is not an API break, I strongly believe it is. It broke compilation of lots of c++ applications (I'll not repeat myself here... in the mailing list there are my other arguments why it is an api breakage) My opinion is to revert the whole thing, but I'm sure this would be a major task after the surgery to put it in was made. I'd at least like the people responsible for it to answer the points above, and people who like me think this is all crap to step up and say so. Lucas De Marchi depressing though it may be to think about, I have to agree with your points. I'm not saying it needs to be reverted, but I don't see any benefit to keeping it unless the goal was to reduce my commits to the afflicted areas to near zero. while it's impressive that all of the eo stuff was added with relatively little breakage (as opposed to my expectations), the idea of having to learn what is essentially a different programming language in order to work on efl internals again in trunk is really demotivating. maybe I'll become the kwo of the 1.7 branch? fair enough. it's a change. it's not a change i wanted. it's a change that was NEEDED. needed because once you go beyond the scope of us few efl devs, you hit a wall of developers who can take our api - documented or not, with examples or Hello, from a new developer pespective, I think Eo is creating an unwelcome encapsulation of the API, that's usually neither expected nor wanted in C. It's replacing simple function calls with message building with handles and varargs. The way I see it, new C application developers from the community (as opposed to employees required to work on EFL) which could potentially choose EFL as a toolkit, would avoid it, not be attracted to it. While developing with Eo I also noticed that it breaks cscope usage. Whenever I wanted to jump to the definition of some method call, I reached a macro in the include file instead. Then I had to use the method ID to do a new search, this time not by definition, but by usage in class
Re: [E-devel] eo and efl
On Sun, Dec 30, 2012 at 9:49 AM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Dec 2012 09:27:40 -0200 Lucas De Marchi lucas.demar...@profusion.mobi said: On Sat, Dec 29, 2012 at 10:32 PM, Carsten Haitzler ras...@rasterman.com wrote: On Sat, 29 Dec 2012 13:06:25 -0200 Henrique Dante hda...@profusion.mobi said: On Sat, Dec 29, 2012 at 12:48 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 28 Dec 2012 22:31:18 + Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Hey! I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. it does make me consider entering one of those code obfuscation contests... - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. backtraces with eo are the reason I don't see myself ever switching to the 1.8 branch. as for benchmarks, I saw some supposed numbers thrown around during early eo development which claimed that it was slower, but not that much slower, and worth it for the gains - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party not to mention the spam just from running e - Despite raster arguing this is not an API break, I strongly believe it is. It broke compilation of lots of c++ applications (I'll not repeat myself here... in the mailing list there are my other arguments why it is an api breakage) My opinion is to revert the whole thing, but I'm sure this would be a major task after the surgery to put it in was made. I'd at least like the people responsible for it to answer the points above, and people who like me think this is all crap to step up and say so. Lucas De Marchi depressing though it may be to think about, I have to agree with your points. I'm not saying it needs to be reverted, but I don't see any benefit to keeping it unless the goal was to reduce my commits to the afflicted areas to near zero. while it's impressive that all of the eo stuff was added with relatively little breakage (as opposed to my expectations), the idea of having to learn what is essentially a different programming language in order to work on efl internals again in trunk is really demotivating. maybe I'll become the kwo of the 1.7 branch? fair enough. it's a change. it's not a change i wanted. it's a change that was NEEDED. needed because once you go beyond the scope of us few efl devs, you hit a wall of developers who can take our api - documented or not, with examples or Hello, from a new developer pespective, I think Eo is creating an unwelcome encapsulation of the API, that's usually neither expected nor wanted in C. It's replacing simple function calls with message building with handles and varargs. The way I see it, new C application developers from the community (as opposed to employees required to work on EFL) which could potentially choose EFL as a toolkit, would avoid it, not be attracted to it. While developing with Eo I also noticed that it breaks cscope usage. Whenever I wanted to jump to the definition of some method call, I reached a macro in the
Re: [E-devel] eo and efl
On Sun, Dec 30, 2012 at 12:55 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: I don't want to be the boring guy complaining on this. But I can't agree neither on the reasons why this went in, nor how it went in. For me eo is just raping C and all the problems pointed out should be fixed elsewhere. Please describe how. For example how do you plan to link cleanly any object from ecore or eio for example with any evas_object ? How do you plan to give memory compaction ? How do you see we could do the ID indirection ? How can we do a live debug of live object in a program ? How do you provide multiple inheritance ? How do you provide API and ABI stability over time ? How do you make bindings easier to keep in sync possible ? Please share your idea. If you dislike Eo so much, you must have an alternative in mind that solve the same issue that Eo solve. At the moment, I only see rants and no care about the problem that Eo address and the answer we have been giving here. -- Cedric BAIL -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Sun, Dec 30, 2012 at 10:04 AM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Dec 30, 2012 at 12:55 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: I don't want to be the boring guy complaining on this. But I can't agree neither on the reasons why this went in, nor how it went in. For me eo is just raping C and all the problems pointed out should be fixed elsewhere. Please describe how. For example how do you plan to link cleanly any object from ecore or eio for example with any evas_object ? How do you plan to give memory compaction ? How do you see we could do the ID indirection ? How can we do a live debug of live object in a program ? How do you provide multiple inheritance ? How do you provide API and ABI stability over time ? How do you make bindings easier to keep in sync possible ? Please share your idea. If you dislike Eo so much, you must have an alternative in mind that solve the same issue that Eo solve. At the moment, I only see rants and no care about the problem that Eo address and the answer we have been giving here. I was trying to stay out of this thread, everybody knows I hate Eo and was against this since the beginning, showing facts on problems it caused to debug. But with these arguments, you're being too naive an eo is the solution for everything is not working. the memory compaction, for example, is independent and either you found out the light that nobody else did, or you'll face huge problems if you try. Not everywhere uses eo_data_get(), then if you replace the memory with some other address underneath, you'll end with lost pointers, garbage and it will be super-hard to find. The change will not be doable in the code base of our size. If may have worked if we started coding like that from day0. ID indirection helps what? making debug harder? ABI/API stability is worse, not better. You still have the same problems you had before, but the existing tools to check that (nm + shell scripts to compare 2 libs) won't work... and the worse part is simple: before you could reorder the functions around, now you must keep them in order as they imply an ID and it can't change. Okay, this is very minimum, but it is worse, not better in that regard. See, you can't still change the parameters. You can't change the return type. You can't change the function name. Bindings: I'm still to see that for real, but IMO it will make bindings worse. Also, people tend to think of bindings as a simply expose C functions in that language 1:1. This is horrible, you're developing for some language and you must cope with that language's style as much as possible. If the work to make the Python or JS bindings were just to generate 1:1, it would be better, but we took the time to think how to match language nicely. For bindings, the worse part here is that you'll never be able to construct va_list then you'll never be abe to expose eo_do() itself. Then it's like fixing a problem that is not broken. Raster had better points, which could be easily fixable in a simpler way (unified callbacks, references, type). The Eo is bringing a problem, not solving one :-( Actually it would be better to have invested in something like Vala, that looks like a higher level language that translates to C, other than doing this in C and having to solve problems everywhere else, like tools, debugger... the so called e ide. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Sun, 30 Dec 2012 09:55:10 -0200 Lucas De Marchi lucas.demar...@profusion.mobi said: On Sun, Dec 30, 2012 at 9:49 AM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Dec 2012 09:27:40 -0200 Lucas De Marchi lucas.demar...@profusion.mobi said: On Sat, Dec 29, 2012 at 10:32 PM, Carsten Haitzler ras...@rasterman.com wrote: On Sat, 29 Dec 2012 13:06:25 -0200 Henrique Dante hda...@profusion.mobi said: On Sat, Dec 29, 2012 at 12:48 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 28 Dec 2012 22:31:18 + Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Hey! I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. it does make me consider entering one of those code obfuscation contests... - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. backtraces with eo are the reason I don't see myself ever switching to the 1.8 branch. as for benchmarks, I saw some supposed numbers thrown around during early eo development which claimed that it was slower, but not that much slower, and worth it for the gains - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party not to mention the spam just from running e - Despite raster arguing this is not an API break, I strongly believe it is. It broke compilation of lots of c++ applications (I'll not repeat myself here... in the mailing list there are my other arguments why it is an api breakage) My opinion is to revert the whole thing, but I'm sure this would be a major task after the surgery to put it in was made. I'd at least like the people responsible for it to answer the points above, and people who like me think this is all crap to step up and say so. Lucas De Marchi depressing though it may be to think about, I have to agree with your points. I'm not saying it needs to be reverted, but I don't see any benefit to keeping it unless the goal was to reduce my commits to the afflicted areas to near zero. while it's impressive that all of the eo stuff was added with relatively little breakage (as opposed to my expectations), the idea of having to learn what is essentially a different programming language in order to work on efl internals again in trunk is really demotivating. maybe I'll become the kwo of the 1.7 branch? fair enough. it's a change. it's not a change i wanted. it's a change that was NEEDED. needed because once you go beyond the scope of us few efl devs, you hit a wall of developers who can take our api - documented or not, with examples or Hello, from a new developer pespective, I think Eo is creating an unwelcome encapsulation of the API, that's usually neither expected nor wanted in C. It's replacing simple function calls with message building with handles and varargs. The way I see it, new C application developers from the community (as opposed to employees required to work on EFL) which could potentially choose EFL as a toolkit, would avoid it, not be attracted to it.
Re: [E-devel] eo and efl
On Sun, Dec 30, 2012 at 12:51 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sun, 30 Dec 2012 09:55:10 -0200 Lucas De Marchi lucas.demar...@profusion.mobi said: On Sun, Dec 30, 2012 at 9:49 AM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Dec 2012 09:27:40 -0200 Lucas De Marchi lucas.demar...@profusion.mobi said: On Sat, Dec 29, 2012 at 10:32 PM, Carsten Haitzler ras...@rasterman.com wrote: On Sat, 29 Dec 2012 13:06:25 -0200 Henrique Dante hda...@profusion.mobi said: On Sat, Dec 29, 2012 at 12:48 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 28 Dec 2012 22:31:18 + Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Hey! I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. it does make me consider entering one of those code obfuscation contests... - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. backtraces with eo are the reason I don't see myself ever switching to the 1.8 branch. as for benchmarks, I saw some supposed numbers thrown around during early eo development which claimed that it was slower, but not that much slower, and worth it for the gains - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party not to mention the spam just from running e - Despite raster arguing this is not an API break, I strongly believe it is. It broke compilation of lots of c++ applications (I'll not repeat myself here... in the mailing list there are my other arguments why it is an api breakage) My opinion is to revert the whole thing, but I'm sure this would be a major task after the surgery to put it in was made. I'd at least like the people responsible for it to answer the points above, and people who like me think this is all crap to step up and say so. Lucas De Marchi depressing though it may be to think about, I have to agree with your points. I'm not saying it needs to be reverted, but I don't see any benefit to keeping it unless the goal was to reduce my commits to the afflicted areas to near zero. while it's impressive that all of the eo stuff was added with relatively little breakage (as opposed to my expectations), the idea of having to learn what is essentially a different programming language in order to work on efl internals again in trunk is really demotivating. maybe I'll become the kwo of the 1.7 branch? fair enough. it's a change. it's not a change i wanted. it's a change that was NEEDED. needed because once you go beyond the scope of us few efl devs, you hit a wall of developers who can take our api - documented or not, with examples or Hello, from a new developer pespective, I think Eo is creating an unwelcome encapsulation of the API, that's usually neither expected nor wanted in C. It's replacing simple function calls with message building with handles and varargs.
Re: [E-devel] eo and efl
On Sun, 30 Dec 2012 13:24:06 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Sun, Dec 30, 2012 at 12:51 PM, Carsten Haitzler ras...@rasterman.comwrote: On Sun, 30 Dec 2012 09:55:10 -0200 Lucas De Marchi lucas.demar...@profusion.mobi said: On Sun, Dec 30, 2012 at 9:49 AM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Dec 2012 09:27:40 -0200 Lucas De Marchi lucas.demar...@profusion.mobi said: On Sat, Dec 29, 2012 at 10:32 PM, Carsten Haitzler ras...@rasterman.com wrote: On Sat, 29 Dec 2012 13:06:25 -0200 Henrique Dante hda...@profusion.mobi said: On Sat, Dec 29, 2012 at 12:48 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 28 Dec 2012 22:31:18 + Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Hey! I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. it does make me consider entering one of those code obfuscation contests... - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. backtraces with eo are the reason I don't see myself ever switching to the 1.8 branch. as for benchmarks, I saw some supposed numbers thrown around during early eo development which claimed that it was slower, but not that much slower, and worth it for the gains - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party not to mention the spam just from running e - Despite raster arguing this is not an API break, I strongly believe it is. It broke compilation of lots of c++ applications (I'll not repeat myself here... in the mailing list there are my other arguments why it is an api breakage) My opinion is to revert the whole thing, but I'm sure this would be a major task after the surgery to put it in was made. I'd at least like the people responsible for it to answer the points above, and people who like me think this is all crap to step up and say so. Lucas De Marchi depressing though it may be to think about, I have to agree with your points. I'm not saying it needs to be reverted, but I don't see any benefit to keeping it unless the goal was to reduce my commits to the afflicted areas to near zero. while it's impressive that all of the eo stuff was added with relatively little breakage (as opposed to my expectations), the idea of having to learn what is essentially a different programming language in order to work on efl internals again in trunk is really demotivating. maybe I'll become the kwo of the 1.7 branch? fair enough. it's a change. it's not a change i wanted. it's a change that was NEEDED. needed because once you go beyond the scope of us few efl devs, you hit a wall of developers who can take our api - documented or not, with examples or Hello, from a
Re: [E-devel] eo and efl
On Sun, Dec 30, 2012 at 12:51 PM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Dec 2012 09:55:10 -0200 Lucas De Marchi lucas.demar...@profusion.mobi said: On Sun, Dec 30, 2012 at 9:49 AM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 30 Dec 2012 09:27:40 -0200 Lucas De Marchi lucas.demar...@profusion.mobi said: On Sat, Dec 29, 2012 at 10:32 PM, Carsten Haitzler ras...@rasterman.com wrote: On Sat, 29 Dec 2012 13:06:25 -0200 Henrique Dante hda...@profusion.mobi said: On Sat, Dec 29, 2012 at 12:48 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 28 Dec 2012 22:31:18 + Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Hey! I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. it does make me consider entering one of those code obfuscation contests... - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. backtraces with eo are the reason I don't see myself ever switching to the 1.8 branch. as for benchmarks, I saw some supposed numbers thrown around during early eo development which claimed that it was slower, but not that much slower, and worth it for the gains - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party not to mention the spam just from running e - Despite raster arguing this is not an API break, I strongly believe it is. It broke compilation of lots of c++ applications (I'll not repeat myself here... in the mailing list there are my other arguments why it is an api breakage) My opinion is to revert the whole thing, but I'm sure this would be a major task after the surgery to put it in was made. I'd at least like the people responsible for it to answer the points above, and people who like me think this is all crap to step up and say so. Lucas De Marchi depressing though it may be to think about, I have to agree with your points. I'm not saying it needs to be reverted, but I don't see any benefit to keeping it unless the goal was to reduce my commits to the afflicted areas to near zero. while it's impressive that all of the eo stuff was added with relatively little breakage (as opposed to my expectations), the idea of having to learn what is essentially a different programming language in order to work on efl internals again in trunk is really demotivating. maybe I'll become the kwo of the 1.7 branch? fair enough. it's a change. it's not a change i wanted. it's a change that was NEEDED. needed because once you go beyond the scope of us few efl devs, you hit a wall of developers who can take our api - documented or not, with examples or Hello, from a new developer pespective, I think Eo is creating an unwelcome encapsulation of the API, that's usually neither expected nor wanted in C. It's replacing simple function calls with message building with handles and varargs. The way I see it, new C application developers from the community (as opposed to employees required to
Re: [E-devel] eo and efl
On Sun, Dec 30, 2012 at 10:04 AM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Dec 30, 2012 at 12:55 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: I don't want to be the boring guy complaining on this. But I can't agree neither on the reasons why this went in, nor how it went in. For me eo is just raping C and all the problems pointed out should be fixed elsewhere. Please describe how. For example how do you plan to link cleanly any object from ecore or eio for example with any evas_object ? How do you plan to give memory compaction ? How do you see we could do the ID indirection ? How can we do a live debug of live object in a program ? How do you provide multiple inheritance ? How do you provide API and ABI stability over time ? How do you make bindings easier to keep in sync possible ? Please share your idea. If you dislike Eo so much, you must have an alternative in mind that solve the same issue that Eo solve. At the moment, I only see rants and no care about the problem that Eo address and the answer we have been giving here. ohh... I and everyone else in the world are missing the cure to cancer tha is eo. You don't solve with eo most of the points above and the ones you solve is in horrible way expecting users to use eo_do() everywhere. And you pay the price of creating more problems like was pointed out already. Needless to say you are creating problems to solve with EO. I don't want multiple inheritance and id indirection, thank you (as I said, maybe this would make sense in elm, where there is some use of multiple inheritance). API/ABI stability is not improved in any way. This is not C, is the eo language. And please don't treat the complaints to your baby as rants. Lucas De Marchi -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Sun, Dec 30, 2012 at 12:06 AM, Henrique Dante hda...@profusion.mobi wrote: While developing with Eo I also noticed that it breaks cscope usage. Whenever I wanted to jump to the definition of some method call, I reached a macro in the include file instead. Then I had to use the method ID to do a new search, this time not by definition, but by usage in class definitions. It took me time to understand what you mean by definition. My understanding of your complaint is that you don't like virtual. cscope will never be able to find the implementation (for me definition is the prototype, that's why I was confused) at compile time, because it is determined at runtime. The same problem exist with C++ and people think that virtual is useful somehow. In fact we need virtual today in EFL for at least to case, for at least to case that I know of. First geometry get on Evas_Object_Text and second for all the *_file_set that lurk around, have the same prototype and do the almost the same think, but just exist to confuse the developer. The other way doesn't work well either: single stepping in gdb to find out the code path or looking at a backtrace are both polluted with Eo calls. In general single stepping on an efl method call should take 5 seconds, but with Eo it may take 5 minutes. Main negative conclusion about this is that there's no trivial way to find out what an Eo call does, and this will discourage new developers from reading code. Did you try Daniel's gdb script for that task ? -- Cedric BAIL -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Sat, Dec 29, 2012 at 3:04 PM, David Seikel onef...@gmail.com wrote: On Sat, 29 Dec 2012 02:14:07 +0100 Cedric BAIL cedric.b...@free.fr wrote: On Fri, Dec 28, 2012 at 11:55 PM, David Seikel onef...@gmail.com However, I've just wasted a whole day tracking down that I was passing an Evas_Object to a function that needed an Evas. It compiled and worked fine under the merged efl tree, but not on EFL 1.7.4. Under 1.7.4 there was no complaints, just missing text. This is cleary a bug, it should have triggered a critical warning at run time. Care to share which function ? edje_object_add() The client is coming around tonight, and now I'm a day behind. So I'm not gonna be spending any more time beating at it to help you diagnose things today. The fact that it just worked perfectly with no error messages in merged efl tree is what took all the time tracking down, coz I was looking everywhere else to find the problem. lol The problem is that it should work with EFL tree. I tested it here and definitively edje_object_add(Evas_Object *parent) does work. It does have the same behavior has elm_*_add function there. Before it was not allowed to pass an Evas_Object instead of an Evas canvas, now it is. So this is not a bug, but an evolution so that all our API match Elm API. Does that explain the behavior you did get ? -- Cedric BAIL -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Sun, Dec 30, 2012 at 10:48 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Sun, Dec 30, 2012 at 10:04 AM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Dec 30, 2012 at 12:55 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: I don't want to be the boring guy complaining on this. But I can't agree neither on the reasons why this went in, nor how it went in. For me eo is just raping C and all the problems pointed out should be fixed elsewhere. Please describe how. For example how do you plan to link cleanly any object from ecore or eio for example with any evas_object ? How do you plan to give memory compaction ? How do you see we could do the ID indirection ? How can we do a live debug of live object in a program ? How do you provide multiple inheritance ? How do you provide API and ABI stability over time ? How do you make bindings easier to keep in sync possible ? Please share your idea. If you dislike Eo so much, you must have an alternative in mind that solve the same issue that Eo solve. At the moment, I only see rants and no care about the problem that Eo address and the answer we have been giving here. I was trying to stay out of this thread, everybody knows I hate Eo and was against this since the beginning, showing facts on problems it caused to debug. But with these arguments, you're being too naive an eo is the solution for everything is not working. the memory compaction, for example, is independent and either you found out the light that nobody else did, or you'll face huge problems if you try. Not everywhere uses eo_data_get(), then if you replace the memory with some other address underneath, you'll end with lost pointers, garbage and it will be super-hard to find. The change will not be doable in the code base of our size. If may have worked if we started coding like that from day0. Indeed the eo_data_get doesn't allow that. I have been working on a proposal to solve that problem and open some more possibility. I planned to write a mail later this week. Anyway the idea is to move to an api like a rw mutex. So that as long as you hold a pointer to it, it wont get compacted. Main target are currently Evas and Edje where it would help and the code affected is not that big (basically mostly in canvas/ subdirectory). ID indirection helps what? making debug harder? You get an assert as soon as you use or reuse a wrong pointer. Instant backtrace that point to the source of the problem. Zero delay. No hiding. It will help application developers that tend to still manipulate dead object. ABI/API stability is worse, not better. You still have the same problems you had before, but the existing tools to check that (nm + shell scripts to compare 2 libs) won't work... and the worse part is simple: before you could reorder the functions around, now you must keep them in order as they imply an ID and it can't change. Okay, this is very minimum, but it is worse, not better in that regard. nm + shell is a very limited tool to check for API/ABI stability. It completely ignore structure and enum. So it's worse but anyway relying on nm + shell for doing an automated test here, is really a wrong argument. If you want this kind of tool, you will need to move to a llvm/clang's plugin anyway and that kind of plugin would be able to check API/ABI stability for EO. See, you can't still change the parameters. You can't change the return type. You can't change the function name. This is not C++, you can change the parameters and return value as long as they remain opaque. As for changing the public name of a function, I don't see how you could still provide an API/ABI compatibility with such a feature. But as we are doing C, API/ABI stability is almost an non issue here compared to other language (which was my main point on that subject). Bindings: I'm still to see that for real, but IMO it will make bindings worse. Also, people tend to think of bindings as a simply expose C functions in that language 1:1. This is horrible, you're developing for some language and you must cope with that language's style as much as possible. If the work to make the Python or JS bindings were just to generate 1:1, it would be better, but we took the time to think how to match language nicely. This is debatable. I do think that a 1:1 binding is fine as it provide an easy and sure path with time. Still there is clearly a need to implement a layer in the binded language to abstract it and make it feel like a native JS, Python, whatever API. You may not have a 1:1 binding in Elev8, but I think you are doing a higher up layer in JS with EasyUI that could have been an abstraction between a 1:1 binding and the JS world. I also think that this way the binding would have a much easier time to provide a stable API and the script could just include the EasyUI layer they used for development. That one would have worked on every version of the binding without any
Re: [E-devel] eo and efl
On Sun, 30 Dec 2012 14:19:01 -0200 Lucas De Marchi lucas.demar...@profusion.mobi said: On Sun, Dec 30, 2012 at 12:51 PM, Carsten Haitzler ras...@rasterman.com wrote: i shall start with a single one: 'Subject: [E-devel] Eobj - Request for review/comments' in april 2012. indeed I missed that. But don't be that silly. Let me explain: wait. you challenge me to provie even 1 example (there's more) and now you dismiss it by saying don't be silly? this line of logic i fail to follow. I just added a project under PROTO/ named ldm with features X, Y and Z. Will you review it? probably not. if you said we want to make this the future of all oo infra in efl and asked for input, i would. 5 month later later I come back and replace all your Eo structs underneath you with my ldm structs, because this is the way I think is the right way. Will you complain? Of course you will. that is nothing like what happened. not even close. you have many opportunities to have input, comment etc. To worse, it was added together with the move of the tree to efl/. And I *DID* complain saying there was no reason to rush eobj in. Of course you didn't hear because a patch like eobj would be impossible to maintain out of tree. indeed it would be impossible - saying i didn't listen is just your way of saying you disagreed therefore i will say you didn't listen. you even provide a justification for disagreing here, and yet... you decide it's not listening. what i see here is there is a change, and i don't like change. i hate change. change means i have to adapt and i hate doing that. i suggest we roll back the async rendering code in evas. it's change. it creates problems. it hasn't solved anything. oh - and edbus. it's change. it's created leaks and crashes and soaked up my time during my vacation. let's roll it back. i hate change. don't be silly. this is EXACTLY what you sound like. you'd now just pulling justifications out of the air to back a desire for no change. And as others pointed out, saying this has been discussed on IRC and mailing list and interpreting that like it has been decided to do this way is just silly. there were 2 main lines of how to solve our oo stuff. gustavo's which was just use smart objects which i said wouldn't fly because we can't make lower level objects use this (timers etc). they are also too heavy-weight for such uses even if we twisted the world. evas canvases then can't ve objects either. they also do not support multiple inheritance (or multiple interfaces) which i listed as a requirement because elm was literally creating objects that did this (scrolled entry for example). i had requirements that went roughly like this: 1. support normal single inheritance 2. multiple inheritance must work sensibly 3. we have to be able to go down to ecore and make timers etc. into objects 4. we have to be able to attach objects to eachother weakly or tightly (weak refs or strong refs) 5. we need to clean up our callback prototype mess and unify 6. we need to make object ptr (handle) access much safer in the event of freed objects or errant (garbage) pointers as well as typechecks 7. since #6 probably is going to raise object access overhead, some way of alleviating this would be really nice 8. we have to be able to slide it under our current api/abi so stuff keeps working as it used to but in future we can migrate to it once slide underneath everywhere 9. support runtime method overriding etc. 10. unify the data attaching we have (evas_object_data_set/get/del) 11. allow for memory compaction/gc to alleviate fragmentation i think i had a few more. some were more important that others, but multiple-inheritance was a big one as it was problematic with just stuffing struct in struct methods of single inheritance gobject did. eo wasn't even created yet. there were toy attempts/exampels in different forms etc. to explore ideas and see what would work or not but nothing concrete. this was the time to have a say. even with the first iterations of eo - it was the time to have a say. eo solves the bove, OR lays the groundwork to be able to solve the above transparently under the hood in future. now you claim eo adds all sorts of problems. the eo_do() is impractical. i just don't get that. it's just as practical as now. obj = evas_object_image_add(evas); evas_object_image_filled_set(obj, EINA_TRUE); evas_object_file_set(obj, blah.jpg, NULL); evas_object_move(obj, 0, 100); evas_object_resize(obj, 200, 100); evas_object_show(obj); very common thing in code. with eo obj = eo_add(evas_object_image_class_get(), evas, evas_obj_image_filled_set(EINA_TRUE), evas_obj_image_file_set(blah.jpg, NULL), evas_obj_position_set(0, 100), evas_obj_size_set(200, 100), evas_obj_visibility_set(EINA_TRUE)); how is that impractical to use? how is it ugly? i've already said that eo_do is not ioctl() - it's vastly different since it doesnt rely
Re: [E-devel] eo and efl
On Sun, Dec 30, 2012 at 9:28 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Dec 30, 2012 at 12:06 AM, Henrique Dante hda...@profusion.mobi wrote: While developing with Eo I also noticed that it breaks cscope usage. Whenever I wanted to jump to the definition of some method call, I reached a macro in the include file instead. Then I had to use the method ID to do a new search, this time not by definition, but by usage in class definitions. It took me time to understand what you mean by definition. My A definition is a declaration that includes the element's content. understanding of your complaint is that you don't like virtual. cscope The way you are saying suggests that I don't like some part of object orientation, which is false. I was strictly referring to the implementation of Eo and its influence on development. will never be able to find the implementation (for me definition is Method calls that were not polymorphic, from concrete classes, were made polymorphic with Eo. And in this case, polymorphic means explicitly referenced by an ID. That's the virtual I didn't like. But even if I liked it, it would have broken jump-to-definition the same way. The problem you mentioned was restricted to a (small ?) subset of methods, the ones derived from base classes. Now the whole libraries have this problem. the prototype, that's why I was confused) at compile time, because it That's a declaration. is determined at runtime. The same problem exist with C++ and people No idea how that's done in C++. I think cscope works with C++ by luck. However in an OO language, a method call bound to a concrete, bottom-of-hierarchy, instanced object should be enough to jump to its definition, at compile time, even if the method is virtual (this should only be harder if it's necessary to walk through the object hierarchy). Anyway, jumping to definition of a virtual method with cscope on a C++ project can be done with 1 search, not 2. think that virtual is useful somehow. Not sure why you're talking about the concept of virtual. My comment was about noticing that developers might avoid EFL because Eo (not OO) has negative effects on development. In fact we need virtual today in EFL for at least to case, for at least to case that I know of. First geometry get on Evas_Object_Text and second for all the *_file_set that lurk around, have the same prototype and do the almost the same think, but just exist to confuse the developer. That looks like there are too few cases to consider it as a benefit. Repeating again, I sent the comment to sugest that Eo could have a negative acceptance by developers. The other way doesn't work well either: single stepping in gdb to find out the code path or looking at a backtrace are both polluted with Eo calls. In general single stepping on an efl method call should take 5 seconds, but with Eo it may take 5 minutes. Main negative conclusion about this is that there's no trivial way to find out what an Eo call does, and this will discourage new developers from reading code. Did you try Daniel's gdb script for that task ? No idea what it is. -- Cedric BAIL -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft There's a Microsoft ad in your e-mail. MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Mon, 31 Dec 2012 09:44:50 +0900 Cedric BAIL cedric.b...@free.fr wrote: On Sat, Dec 29, 2012 at 3:04 PM, David Seikel onef...@gmail.com wrote: On Sat, 29 Dec 2012 02:14:07 +0100 Cedric BAIL cedric.b...@free.fr wrote: On Fri, Dec 28, 2012 at 11:55 PM, David Seikel onef...@gmail.com However, I've just wasted a whole day tracking down that I was passing an Evas_Object to a function that needed an Evas. It compiled and worked fine under the merged efl tree, but not on EFL 1.7.4. Under 1.7.4 there was no complaints, just missing text. This is cleary a bug, it should have triggered a critical warning at run time. Care to share which function ? edje_object_add() The client is coming around tonight, and now I'm a day behind. So I'm not gonna be spending any more time beating at it to help you diagnose things today. The fact that it just worked perfectly with no error messages in merged efl tree is what took all the time tracking down, coz I was looking everywhere else to find the problem. lol The problem is that it should work with EFL tree. I tested it here and definitively edje_object_add(Evas_Object *parent) does work. It does have the same behavior has elm_*_add function there. Before it was not allowed to pass an Evas_Object instead of an Evas canvas, now it is. So this is not a bug, but an evolution so that all our API match Elm API. Does that explain the behavior you did get ? That explains the behaviour. It just did not help to track down the problem I had. Perhaps this evolution should be documented? I do the major development for this embedded project on my workstation, then later double check it on an emulator, then test it on the real hardware. It's nice and quick using the workstation, but very slow to make the version for the emulator and hardware. The hardware has to use the latest EFL released tarball, but recently I've been using merged EFL tree on my workstation. My problem is solved now, and the client is happy. I get the rest of the year off now. All 11 hours of it. lol -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Mon, 31 Dec 2012 10:20:21 +0900 Cedric BAIL cedric.b...@free.fr wrote: On Sun, Dec 30, 2012 at 10:48 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Sun, Dec 30, 2012 at 10:04 AM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Dec 30, 2012 at 12:55 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: snip Bindings: I'm still to see that for real, but IMO it will make bindings worse. Also, people tend to think of bindings as a simply expose C functions in that language 1:1. This is horrible, you're developing for some language and you must cope with that language's style as much as possible. If the work to make the Python or JS bindings were just to generate 1:1, it would be better, but we took the time to think how to match language nicely. This is debatable. I do think that a 1:1 binding is fine as it provide an easy and sure path with time. Still there is clearly a need to implement a layer in the binded language to abstract it and make it feel like a native JS, Python, whatever API. You may not have a 1:1 binding in Elev8, but I think you are doing a higher up layer in JS with EasyUI that could have been an abstraction between a 1:1 binding and the JS world. I also think that this way the binding would have a much easier time to provide a stable API and the script could just include the EasyUI layer they used for development. That one would have worked on every version of the binding without any breakage ever and it would have make the life of maintaining that binding much more easy. For bindings, the worse part here is that you'll never be able to construct va_list then you'll never be abe to expose eo_do() itself. It's not worse, it just limiting and sad. You will be limited to use only one function call even when you have all the value needed to do much more... I also would have liked a way to bind that. Then it's like fixing a problem that is not broken. Seriously ? Our binding are massively behind. We have barely one maintained binding, JS and a few other that are slowly dying. If half of our API was present in them, I would be happy, but that's far from being the case. So what is the status of the Perl, Python, Ruby, Go and all other bindings ? Tell me they are all great, cover 80% of our API (I am not even asking for 100%) and well maintained. The Lua bindings are great, well maintained, but only cover a small percentage of EFL API. They also try to leverage Lua ways of doing stuff to make it easy for Lua scripters, it's not exactly a 1:1 binding. It's close to 1:1 though. It's not slowly dying. :-P I would love to resurrect my ancient RAD tool and have some higher level stuff for edje Lua, but I suspect Raster would veto that. I'm not ready to do that yet anyway, so will leave that for a later discussion. The textblock API is kinda scary huge, that's why I left it out last time I was adding Lua bindings. Which bit me last week when I was considering a design that would use textblock from Lua. lol BTW, no one answered my previous question - will I have to redo the Lua bindings to suit eo now? -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Mon, 31 Dec 2012 10:33:30 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: snip eo to some very minor extent does kind of invent a new lang within c. i mulled the idea of an added pre-processor at compile time to be able to add things like namespacing and cutting down typing fluff but others rejected the idea. it didn't happen - ok. fair enough. it'd be c PLUS some efl speciic language extensions in a preprocessor much smarter than cpp. c++ would entail a massive change much more invasive than eo and it'd come with other side-effects too like the complaints of build times and memory needed just to build efl from eveyr dev. your complaints herew oudl jsut morph into other peoples complaints about this. One other problem with a change to C++, I would leave, and I suspect many others would to. Though I'm sure there would be an influx of new C++ developers to compensate. It's not that I don't know C++, I've been doing C++ programming professionally for over a decade. I just much prefer C to C++. Very strongly prefer. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Mon, 31 Dec 2012 01:24:03 -0200 Henrique Dante hda...@profusion.mobi wrote: On Sun, Dec 30, 2012 at 9:28 PM, Cedric BAIL cedric.b...@free.fr wrote: snip -- Cedric BAIL -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft There's a Microsoft ad in your e-mail. MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel Oh look, there's a Microsoft advert in your email to. There likely will be one in mine. It gets added by the SourceForge mailing list. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Mon, Dec 31, 2012 at 12:24 PM, Henrique Dante hda...@profusion.mobi wrote: On Sun, Dec 30, 2012 at 9:28 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Dec 30, 2012 at 12:06 AM, Henrique Dante hda...@profusion.mobi wrote: While developing with Eo I also noticed that it breaks cscope usage. Whenever I wanted to jump to the definition of some method call, I reached a macro in the include file instead. Then I had to use the method ID to do a new search, this time not by definition, but by usage in class definitions. It took me time to understand what you mean by definition. My A definition is a declaration that includes the element's content. Your definition is still vague when speaking about macro, prototype and implementation. understanding of your complaint is that you don't like virtual. cscope The way you are saying suggests that I don't like some part of object orientation, which is false. I was strictly referring to the implementation of Eo and its influence on development. will never be able to find the implementation (for me definition is Method calls that were not polymorphic, from concrete classes, were made polymorphic with Eo. And in this case, polymorphic means explicitly referenced by an ID. That's the virtual I didn't like. But even if I liked it, it would have broken jump-to-definition the same way. Jump to declaration is not broken and provide documentation, prototype for said call. That what developer using EFL are looking for. The problem you mentioned was restricted to a (small ?) subset of methods, the ones derived from base classes. Now the whole libraries have this problem. the prototype, that's why I was confused) at compile time, because it That's a declaration. is determined at runtime. The same problem exist with C++ and people No idea how that's done in C++. I think cscope works with C++ by luck. However in an OO language, a method call bound to a concrete, bottom-of-hierarchy, instanced object should be enough to jump to its definition, at compile time, even if the method is virtual (this should only be harder if it's necessary to walk through the object hierarchy). Anyway, jumping to definition of a virtual method with cscope on a C++ project can be done with 1 search, not 2. So now, I don't follow you anymore. Jumping to the prototype of a virtual in C++ work exactly the same way it work in C. At least from an user of the API. I think I now do understand what you mean. You are doing development inside EFL and try to find the macro that correspond to a function implementation, right ? As a matter of fixing that issue, couldn't you not instruct csope to do the double jump for you ? It doesn't sounds like the problem is more a limitation in your tool than a real issue. think that virtual is useful somehow. Not sure why you're talking about the concept of virtual. My comment was about noticing that developers might avoid EFL because Eo (not OO) has negative effects on development. Maybe because your explanation is confusing. I was supposing you were writing application with EFL and did use the EO API and where complaining about that. Now I think you are trying to work inside EFL with EO API and are complaining about some limitation of your tool. In fact we need virtual today in EFL for at least to case, for at least to case that I know of. First geometry get on Evas_Object_Text and second for all the *_file_set that lurk around, have the same prototype and do the almost the same think, but just exist to confuse the developer. That looks like there are too few cases to consider it as a benefit. That's just the two first example that came to me without having the need to search for anything. I am sure there is more. Making a non virtual and virtual function call would have added a layer of complexity and risk for API/ABI break later. It's a trade-of . Repeating again, I sent the comment to sugest that Eo could have a negative acceptance by developers. It was difficult to understand the context of your remark. Now, I think you are trying to get used to EFL source code and Eo is another bit of complexity in that picture. I guess you never looked at GObject :-) In all object model implemented in C, there is some boiler plate like that. Eo come with its own. The other way doesn't work well either: single stepping in gdb to find out the code path or looking at a backtrace are both polluted with Eo calls. In general single stepping on an efl method call should take 5 seconds, but with Eo it may take 5 minutes. Main negative conclusion about this is that there's no trivial way to find out what an Eo call does, and this will discourage new developers from reading code. Did you try Daniel's gdb script for that task ? No idea what it is. efl/data/eo/eo_step.py. -- Cedric BAIL -- Master Visual Studio, SharePoint,
Re: [E-devel] eo and efl
On 12/31/2012 06:15 AM, Cedric BAIL wrote: On Mon, Dec 31, 2012 at 12:24 PM, Henrique Dante hda...@profusion.mobi wrote: On Sun, Dec 30, 2012 at 9:28 PM, Cedric BAIL cedric.b...@free.fr wrote: On Sun, Dec 30, 2012 at 12:06 AM, Henrique Dante hda...@profusion.mobi wrote: While developing with Eo I also noticed that it breaks cscope usage. Whenever I wanted to jump to the definition of some method call, I reached a macro in the include file instead. Then I had to use the method ID to do a new search, this time not by definition, but by usage in class definitions. It took me time to understand what you mean by definition. My A definition is a declaration that includes the element's content. Your definition is still vague when speaking about macro, prototype and implementation. understanding of your complaint is that you don't like virtual. cscope The way you are saying suggests that I don't like some part of object orientation, which is false. I was strictly referring to the implementation of Eo and its influence on development. will never be able to find the implementation (for me definition is Method calls that were not polymorphic, from concrete classes, were made polymorphic with Eo. And in this case, polymorphic means explicitly referenced by an ID. That's the virtual I didn't like. But even if I liked it, it would have broken jump-to-definition the same way. Jump to declaration is not broken and provide documentation, prototype for said call. That what developer using EFL are looking for. The problem you mentioned was restricted to a (small ?) subset of methods, the ones derived from base classes. Now the whole libraries have this problem. the prototype, that's why I was confused) at compile time, because it That's a declaration. is determined at runtime. The same problem exist with C++ and people No idea how that's done in C++. I think cscope works with C++ by luck. However in an OO language, a method call bound to a concrete, bottom-of-hierarchy, instanced object should be enough to jump to its definition, at compile time, even if the method is virtual (this should only be harder if it's necessary to walk through the object hierarchy). Anyway, jumping to definition of a virtual method with cscope on a C++ project can be done with 1 search, not 2. So now, I don't follow you anymore. Jumping to the prototype of a virtual in C++ work exactly the same way it work in C. At least from an user of the API. I think I now do understand what you mean. You are doing development inside EFL and try to find the macro that correspond to a function implementation, right ? As a matter of fixing that issue, couldn't you not instruct csope to do the double jump for you ? It doesn't sounds like the problem is more a limitation in your tool than a real issue. think that virtual is useful somehow. Not sure why you're talking about the concept of virtual. My comment was about noticing that developers might avoid EFL because Eo (not OO) has negative effects on development. Maybe because your explanation is confusing. I was supposing you were writing application with EFL and did use the EO API and where complaining about that. Now I think you are trying to work inside EFL with EO API and are complaining about some limitation of your tool. In fact we need virtual today in EFL for at least to case, for at least to case that I know of. First geometry get on Evas_Object_Text and second for all the *_file_set that lurk around, have the same prototype and do the almost the same think, but just exist to confuse the developer. That looks like there are too few cases to consider it as a benefit. That's just the two first example that came to me without having the need to search for anything. I am sure there is more. Making a non virtual and virtual function call would have added a layer of complexity and risk for API/ABI break later. It's a trade-of . Repeating again, I sent the comment to sugest that Eo could have a negative acceptance by developers. It was difficult to understand the context of your remark. Now, I think you are trying to get used to EFL source code and Eo is another bit of complexity in that picture. I guess you never looked at GObject :-) In all object model implemented in C, there is some boiler plate like that. Eo come with its own. The other way doesn't work well either: single stepping in gdb to find out the code path or looking at a backtrace are both polluted with Eo calls. In general single stepping on an efl method call should take 5 seconds, but with Eo it may take 5 minutes. Main negative conclusion about this is that there's no trivial way to find out what an Eo call does, and this will discourage new developers from reading code. Did you try Daniel's gdb script for that task ? No idea what it is. efl/data/eo/eo_step.py. eo_step has been committed in revision 80760. Check the log to
Re: [E-devel] eo and efl
On Sat, 29 Dec 2012 11:48:36 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Fri, 28 Dec 2012 22:31:18 + Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Hey! I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. it does make me consider entering one of those code obfuscation contests... - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. backtraces with eo are the reason I don't see myself ever switching to the 1.8 branch. as for benchmarks, I saw some supposed numbers thrown around during early eo development which claimed that it was slower, but not that much slower, and worth it for the gains - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party not to mention the spam just from running e - Despite raster arguing this is not an API break, I strongly believe it is. It broke compilation of lots of c++ applications (I'll not repeat myself here... in the mailing list there are my other arguments why it is an api breakage) My opinion is to revert the whole thing, but I'm sure this would be a major task after the surgery to put it in was made. I'd at least like the people responsible for it to answer the points above, and people who like me think this is all crap to step up and say so. Lucas De Marchi depressing though it may be to think about, I have to agree with your points. I'm not saying it needs to be reverted, but I don't see any benefit to keeping it unless the goal was to reduce my commits to the afflicted areas to near zero. while it's impressive that all of the eo stuff was added with relatively little breakage (as opposed to my expectations), the idea of having to learn what is essentially a different programming language in order to work on efl internals again in trunk is really demotivating. maybe I'll become the kwo of the 1.7 branch? fair enough. it's a change. it's not a change i wanted. it's a change that was NEEDED. needed because once you go beyond the scope of us few efl devs, you hit a wall of developers who can take our api - documented or not, with examples or not, and then just fall over tehmselves and end up wasting our time by the bucket load in the process. you never experienced it so you never felt or sw the pain. you were insulated. this change is some of that insualtion not able to continue and something has to leak. it has to give. if this demotivates you, then i guess, so be it. continuing as we were would have demotivated me to the point of giving up. it also *HAS* deotivated a dozen+ other people. so we lose either way. without eo peolpe doing bindings do them the hard way - forever. eo provides for introspection and documentation. without eo we have our 17 ways to a callback. maybe you don't get annoyed by this, but i do. i keep having to try remember ok, which prototype was that callback? i know its void *data... then what? what does it return?. eo tries to unify callbacks... AND document them at runtime even (for introspection purposes). this makes it insanely easier to build a gui builder and make language bindings. without eo we still have the danger that
Re: [E-devel] eo and efl
On Sat, Dec 29, 2012 at 12:48 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 28 Dec 2012 22:31:18 + Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Hey! I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. it does make me consider entering one of those code obfuscation contests... - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. backtraces with eo are the reason I don't see myself ever switching to the 1.8 branch. as for benchmarks, I saw some supposed numbers thrown around during early eo development which claimed that it was slower, but not that much slower, and worth it for the gains - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party not to mention the spam just from running e - Despite raster arguing this is not an API break, I strongly believe it is. It broke compilation of lots of c++ applications (I'll not repeat myself here... in the mailing list there are my other arguments why it is an api breakage) My opinion is to revert the whole thing, but I'm sure this would be a major task after the surgery to put it in was made. I'd at least like the people responsible for it to answer the points above, and people who like me think this is all crap to step up and say so. Lucas De Marchi depressing though it may be to think about, I have to agree with your points. I'm not saying it needs to be reverted, but I don't see any benefit to keeping it unless the goal was to reduce my commits to the afflicted areas to near zero. while it's impressive that all of the eo stuff was added with relatively little breakage (as opposed to my expectations), the idea of having to learn what is essentially a different programming language in order to work on efl internals again in trunk is really demotivating. maybe I'll become the kwo of the 1.7 branch? fair enough. it's a change. it's not a change i wanted. it's a change that was NEEDED. needed because once you go beyond the scope of us few efl devs, you hit a wall of developers who can take our api - documented or not, with examples or Hello, from a new developer pespective, I think Eo is creating an unwelcome encapsulation of the API, that's usually neither expected nor wanted in C. It's replacing simple function calls with message building with handles and varargs. The way I see it, new C application developers from the community (as opposed to employees required to work on EFL) which could potentially choose EFL as a toolkit, would avoid it, not be attracted to it. While developing with Eo I also noticed that it breaks cscope usage. Whenever I wanted to jump to the definition of some method call, I reached a macro in the include file instead. Then I had to use the method ID to do a new search, this time not by definition, but by usage in class definitions. The other way doesn't work well either: single stepping in gdb to find out the code path or looking at a backtrace are both polluted with Eo calls. In general single stepping on an efl method call should take 5 seconds, but with Eo it may take 5 minutes. Main negative conclusion about this is that there's no trivial way to find out what an Eo call does, and this will discourage new developers from reading code. not, and then just fall over
Re: [E-devel] eo and efl
On Sat, 29 Dec 2012 13:06:25 -0200 Henrique Dante hda...@profusion.mobi said: On Sat, Dec 29, 2012 at 12:48 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 28 Dec 2012 22:31:18 + Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Hey! I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. it does make me consider entering one of those code obfuscation contests... - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. backtraces with eo are the reason I don't see myself ever switching to the 1.8 branch. as for benchmarks, I saw some supposed numbers thrown around during early eo development which claimed that it was slower, but not that much slower, and worth it for the gains - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party not to mention the spam just from running e - Despite raster arguing this is not an API break, I strongly believe it is. It broke compilation of lots of c++ applications (I'll not repeat myself here... in the mailing list there are my other arguments why it is an api breakage) My opinion is to revert the whole thing, but I'm sure this would be a major task after the surgery to put it in was made. I'd at least like the people responsible for it to answer the points above, and people who like me think this is all crap to step up and say so. Lucas De Marchi depressing though it may be to think about, I have to agree with your points. I'm not saying it needs to be reverted, but I don't see any benefit to keeping it unless the goal was to reduce my commits to the afflicted areas to near zero. while it's impressive that all of the eo stuff was added with relatively little breakage (as opposed to my expectations), the idea of having to learn what is essentially a different programming language in order to work on efl internals again in trunk is really demotivating. maybe I'll become the kwo of the 1.7 branch? fair enough. it's a change. it's not a change i wanted. it's a change that was NEEDED. needed because once you go beyond the scope of us few efl devs, you hit a wall of developers who can take our api - documented or not, with examples or Hello, from a new developer pespective, I think Eo is creating an unwelcome encapsulation of the API, that's usually neither expected nor wanted in C. It's replacing simple function calls with message building with handles and varargs. The way I see it, new C application developers from the community (as opposed to employees required to work on EFL) which could potentially choose EFL as a toolkit, would avoid it, not be attracted to it. While developing with Eo I also noticed that it breaks cscope usage. Whenever I wanted to jump to the definition of some method call, I reached a macro in the include file instead. Then I had to use the method ID to do a new search, this time not by definition, but by usage in class definitions. The other way doesn't work well either: single stepping in gdb to find out the code path or looking at a backtrace are both polluted with Eo calls. In general single stepping on an efl method call should take 5 seconds, but with Eo it may take 5 minutes. Main
Re: [E-devel] eo and efl
2012/12/29 Carsten Haitzler ras...@rasterman.com reality is day in and out people turn up looking at efl as a single unit. When will EFL be a single unit? What release? I think I'll have free time to help with the C++ binding in a few months. -- Vinícius dos Santos Oliveira https://plus.google.com/118295250366112843114 http://vinipsmaker.wordpress.com/ Linux user #481186 Majoring in Computer Science (UFAL) -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Sat, 29 Dec 2012 21:39:13 -0300 Vinícius dos Santos Oliveira vini.ipsma...@gmail.com said: 2012/12/29 Carsten Haitzler ras...@rasterman.com reality is day in and out people turn up looking at efl as a single unit. When will EFL be a single unit? What release? I think I'll have free time to help with the C++ binding in a few months. well we're already well on the way to having a single src tree. this may be many releases down the road until we build single libefl.so's - it's still debatable if we make 1 or to eg libeflcore.so libeflui.so etc. to split things involved in ui from core back-end thigs that are useful for non-ui stuff like servers etc. - but the first step is a single tree. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] eo and efl
Hey! I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party - Despite raster arguing this is not an API break, I strongly believe it is. It broke compilation of lots of c++ applications (I'll not repeat myself here... in the mailing list there are my other arguments why it is an api breakage) My opinion is to revert the whole thing, but I'm sure this would be a major task after the surgery to put it in was made. I'd at least like the people responsible for it to answer the points above, and people who like me think this is all crap to step up and say so. Lucas De Marchi -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Hey! I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. it does make me consider entering one of those code obfuscation contests... - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. backtraces with eo are the reason I don't see myself ever switching to the 1.8 branch. as for benchmarks, I saw some supposed numbers thrown around during early eo development which claimed that it was slower, but not that much slower, and worth it for the gains - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party not to mention the spam just from running e - Despite raster arguing this is not an API break, I strongly believe it is. It broke compilation of lots of c++ applications (I'll not repeat myself here... in the mailing list there are my other arguments why it is an api breakage) My opinion is to revert the whole thing, but I'm sure this would be a major task after the surgery to put it in was made. I'd at least like the people responsible for it to answer the points above, and people who like me think this is all crap to step up and say so. Lucas De Marchi depressing though it may be to think about, I have to agree with your points. I'm not saying it needs to be reverted, but I don't see any benefit to keeping it unless the goal was to reduce my commits to the afflicted areas to near zero. while it's impressive that all of the eo stuff was added with relatively little breakage (as opposed to my expectations), the idea of having to learn what is essentially a different programming language in order to work on efl internals again in trunk is really demotivating. maybe I'll become the kwo of the 1.7 branch? -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Fri, 28 Dec 2012 22:31:18 + Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Hey! I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. it does make me consider entering one of those code obfuscation contests... - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. backtraces with eo are the reason I don't see myself ever switching to the 1.8 branch. as for benchmarks, I saw some supposed numbers thrown around during early eo development which claimed that it was slower, but not that much slower, and worth it for the gains - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party not to mention the spam just from running e - Despite raster arguing this is not an API break, I strongly believe it is. It broke compilation of lots of c++ applications (I'll not repeat myself here... in the mailing list there are my other arguments why it is an api breakage) My opinion is to revert the whole thing, but I'm sure this would be a major task after the surgery to put it in was made. I'd at least like the people responsible for it to answer the points above, and people who like me think this is all crap to step up and say so. Lucas De Marchi depressing though it may be to think about, I have to agree with your points. I'm not saying it needs to be reverted, but I don't see any benefit to keeping it unless the goal was to reduce my commits to the afflicted areas to near zero. while it's impressive that all of the eo stuff was added with relatively little breakage (as opposed to my expectations), the idea of having to learn what is essentially a different programming language in order to work on efl internals again in trunk is really demotivating. maybe I'll become the kwo of the 1.7 branch? I'll add my two cents worth. Initially I think I was keen on the idea, but was waiting to see what the implementation was like. It did worry me that we seemed to be getting more than one OO system being worked on at the same time. However, I've just wasted a whole day tracking down that I was passing an Evas_Object to a function that needed an Evas. It compiled and worked fine under the merged efl tree, but not on EFL 1.7.4. Under 1.7.4 there was no complaints, just missing text. So today, I don't like the implementation. I've not actually studied it though, just pissed off after today's wasted work. There may be things about it I actually like if I bother to look at it. lol -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
Hello, On Fri, Dec 28, 2012 at 11:17 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. It does, just everything is not done yet. See below. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. Why ? You have less to type than before and you can now mix function call from different name space. It does bring benefit by reducing the need to check EINA_MAGIC for every API call for example. It still provide type checking to some extent at compile time. It also open up some load time improvement by reducing the number of symbol to link. Later on we can split the enum and the legacy api in two library, so application that only use eo_do will have the benefit of a faster startup time. By having one entry point we can now improve our debugging infra quite a lot. For example, instead of returning pointer, we can return an ID and check if it is still valid before touching it avoiding safely all use after evas_object_del for example. We now have weak reference and refcounting. There is also some possibility to reduce memory usage and run some gc to compact memory as needed. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. As far as I know ioctl doesn't have any type checking at compile time. - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. I did benchmark at every point when this was added in trunk. You will see some patch from me in evas_render code that was linked to some speed regression. Over all expedite suffer a less than 5% slow down (without using directly eo_do API). - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. C++ is not really sweeted for ABI/API stability ( for reference : http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ ). With EO, we only have two rules to follow: only add new enum at the end of the enum list and never remove any inheritance link. Every think else is good to go. That's of course without talking about startup time... And also live debugging feature. There is an ongoing work on integrating clouseau and eo. This mean we will be able to also walk the list of all live object in a running program. For large program like Enlightenment, this open up the possibility to check how many idler, timer, animator, ... are sitting around and how we can optimize our stack. That's why moving Ecore to Eo make sense. One infra that help every one. In fact Eo will help us a lot in writing an EFL IDE. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? Because smart object is really far from any useful object model. No multi inheritance. Highly tied to evas_object... I will let you continue on that list, just look at Eo feature and you will see everything that smart object are lacking and can't get. - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party That is something I think is annoying to. It is clearly to much verbose for nothing, should be fixed in my opinion. - Despite raster arguing this is not an API break, I strongly believe it is. It broke compilation of lots of c++ applications (I'll not repeat myself here... in the mailing list there are my other arguments why it is an api breakage) Yes, in C++ you can't change a returned type ever or it break ABI/API. That's a C++ issue. Regarding C++, it is now much more easy to provide a clean binding to EFL that will have much less chance to have his ABI/API break. -- Cedric BAIL -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with
Re: [E-devel] eo and efl
On Fri, Dec 28, 2012 at 11:55 PM, David Seikel onef...@gmail.com wrote: On Fri, 28 Dec 2012 22:31:18 + Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Hey! I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. it does make me consider entering one of those code obfuscation contests... - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. backtraces with eo are the reason I don't see myself ever switching to the 1.8 branch. as for benchmarks, I saw some supposed numbers thrown around during early eo development which claimed that it was slower, but not that much slower, and worth it for the gains - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party not to mention the spam just from running e - Despite raster arguing this is not an API break, I strongly believe it is. It broke compilation of lots of c++ applications (I'll not repeat myself here... in the mailing list there are my other arguments why it is an api breakage) My opinion is to revert the whole thing, but I'm sure this would be a major task after the surgery to put it in was made. I'd at least like the people responsible for it to answer the points above, and people who like me think this is all crap to step up and say so. Lucas De Marchi depressing though it may be to think about, I have to agree with your points. I'm not saying it needs to be reverted, but I don't see any benefit to keeping it unless the goal was to reduce my commits to the afflicted areas to near zero. while it's impressive that all of the eo stuff was added with relatively little breakage (as opposed to my expectations), the idea of having to learn what is essentially a different programming language in order to work on efl internals again in trunk is really demotivating. maybe I'll become the kwo of the 1.7 branch? I'll add my two cents worth. Initially I think I was keen on the idea, but was waiting to see what the implementation was like. It did worry me that we seemed to be getting more than one OO system being worked on at the same time. However, I've just wasted a whole day tracking down that I was passing an Evas_Object to a function that needed an Evas. It compiled and worked fine under the merged efl tree, but not on EFL 1.7.4. Under 1.7.4 there was no complaints, just missing text. This is cleary a bug, it should have triggered a critical warning at run time. Care to share which function ? -- Cedric BAIL -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eo and efl
On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi lucas.demar...@profusion.mobi said: Hey! I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. it makes no sense to put in elm unless the base of efl also has it. a whole POINT of eo is so you can do things like attached a timer as a child to button and have it auto-deleted when the button is. in the end this all requires that anything you want to work this way has to be an eo obj. this is a result of real life problems with programmers doing things like making animators and timers and simply never cleaning them up when the parent object they worked on was deleted. they neve bothered to attach a del calback and track these things and then others end up with their days wasted hunting down these bugs because there wasn't a sensible and easy way to bind such thnigs together. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. anyting systray related makes my eyes bleed. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. disagree. what we can do now is ammortise call costs eo_do(obj, move(10, 20), resize(30, 50), color(255, 128, 0, 255), show()); we have only 1 entry cost (eo_do). all the magic checks and so on are done onces for all of move+resize+color+show. there is a good reason for this. one of the intents of eo is to indirect object ptrs. frankly as above. people who can't read backtraces properly or handle memory well are wasting efl devs time aain and again. i want object ptrs gone. that means obj * is actually going to become an ID and then an indirect table lookup. it's set up in such a way that it then impossible to access memory accidentally from an object handle. you either access valid memory or you know its empty. this raises the entry cost. offsetting that with multi-call per entry evens things out. my only unhappiness is lack of namespacing in c so we could have shotened the func macros to the above. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. vastly different. ioctl is used as a one-thing-at-a-time stuff every func on the planet into ioctl via params. eo_do() is a protocol buffer. like write() but the compiler builds the protcol buffer for you on the stack which is much nicer. no it's not async. but its not ioctl(). very far from it. the only similarity is that it has a single entry point parent. (well actuallt you can do the same on eo_add - pass multiple method calls WHILE adding the obj so once returned the obj is already set up). - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. benchmarks have been done - it depends what you benchmark and how. it's in the 0-10% range of overhead. this was already expcted and a price we know we have to pay in return for other things. if you USE is as 1 eo_do() == 1 old evas/edje etc. func - then yes - expect that overehad. if you make use of the multi-call stuff.. overhead drops a lot. in fact you may begin to gain as we currently do magic number and ptr checks for every efl call. eo will ammortise its higher check cost over N calls, as long as you try and kep N 1 then you're on the path to winning. - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. c++ would be a sledgehammer solution and comes with lots of downsides of its own. other languages too. the fact is we can slide eo in without rewriting in another language. the only thing really missing is namespacing. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? see above. need ot lower down. also smart objects are evas objects. evas objects are big, fat and bulky. they consume a lot of memory. - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party that was there already. we alloc and free events all the time. we construct and destruct
Re: [E-devel] eo and efl
On Fri, 28 Dec 2012 22:31:18 + Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Hey! I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. it does make me consider entering one of those code obfuscation contests... - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. backtraces with eo are the reason I don't see myself ever switching to the 1.8 branch. as for benchmarks, I saw some supposed numbers thrown around during early eo development which claimed that it was slower, but not that much slower, and worth it for the gains - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party not to mention the spam just from running e - Despite raster arguing this is not an API break, I strongly believe it is. It broke compilation of lots of c++ applications (I'll not repeat myself here... in the mailing list there are my other arguments why it is an api breakage) My opinion is to revert the whole thing, but I'm sure this would be a major task after the surgery to put it in was made. I'd at least like the people responsible for it to answer the points above, and people who like me think this is all crap to step up and say so. Lucas De Marchi depressing though it may be to think about, I have to agree with your points. I'm not saying it needs to be reverted, but I don't see any benefit to keeping it unless the goal was to reduce my commits to the afflicted areas to near zero. while it's impressive that all of the eo stuff was added with relatively little breakage (as opposed to my expectations), the idea of having to learn what is essentially a different programming language in order to work on efl internals again in trunk is really demotivating. maybe I'll become the kwo of the 1.7 branch? fair enough. it's a change. it's not a change i wanted. it's a change that was NEEDED. needed because once you go beyond the scope of us few efl devs, you hit a wall of developers who can take our api - documented or not, with examples or not, and then just fall over tehmselves and end up wasting our time by the bucket load in the process. you never experienced it so you never felt or sw the pain. you were insulated. this change is some of that insualtion not able to continue and something has to leak. it has to give. if this demotivates you, then i guess, so be it. continuing as we were would have demotivated me to the point of giving up. it also *HAS* deotivated a dozen+ other people. so we lose either way. without eo peolpe doing bindings do them the hard way - forever. eo provides for introspection and documentation. without eo we have our 17 ways to a callback. maybe you don't get annoyed by this, but i do. i keep having to try remember ok, which prototype was that callback? i know its void *data... then what? what does it return?. eo tries to unify callbacks... AND document them at runtime even (for introspection purposes). this makes it insanely easier to build a gui builder and make language bindings. without eo we still have the danger that code messes up and you accidetnally access an invalid pointer... nd then segv. and hen you should know the wonders of this... you get a complaint e crashes!... and you get no usefl backtrace from the user (or not even
Re: [E-devel] eo and efl
On Sat, 29 Dec 2012 02:14:07 +0100 Cedric BAIL cedric.b...@free.fr wrote: On Fri, Dec 28, 2012 at 11:55 PM, David Seikel onef...@gmail.com wrote: On Fri, 28 Dec 2012 22:31:18 + Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Hey! I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. it does make me consider entering one of those code obfuscation contests... - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. backtraces with eo are the reason I don't see myself ever switching to the 1.8 branch. as for benchmarks, I saw some supposed numbers thrown around during early eo development which claimed that it was slower, but not that much slower, and worth it for the gains - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party not to mention the spam just from running e - Despite raster arguing this is not an API break, I strongly believe it is. It broke compilation of lots of c++ applications (I'll not repeat myself here... in the mailing list there are my other arguments why it is an api breakage) My opinion is to revert the whole thing, but I'm sure this would be a major task after the surgery to put it in was made. I'd at least like the people responsible for it to answer the points above, and people who like me think this is all crap to step up and say so. Lucas De Marchi depressing though it may be to think about, I have to agree with your points. I'm not saying it needs to be reverted, but I don't see any benefit to keeping it unless the goal was to reduce my commits to the afflicted areas to near zero. while it's impressive that all of the eo stuff was added with relatively little breakage (as opposed to my expectations), the idea of having to learn what is essentially a different programming language in order to work on efl internals again in trunk is really demotivating. maybe I'll become the kwo of the 1.7 branch? I'll add my two cents worth. Initially I think I was keen on the idea, but was waiting to see what the implementation was like. It did worry me that we seemed to be getting more than one OO system being worked on at the same time. However, I've just wasted a whole day tracking down that I was passing an Evas_Object to a function that needed an Evas. It compiled and worked fine under the merged efl tree, but not on EFL 1.7.4. Under 1.7.4 there was no complaints, just missing text. This is cleary a bug, it should have triggered a critical warning at run time. Care to share which function ? edje_object_add() The client is coming around tonight, and now I'm a day behind. So I'm not gonna be spending any more time beating at it to help you diagnose things today. The fact that it just worked perfectly with no error messages in merged efl tree is what took all the time tracking down, coz I was looking everywhere else to find the problem. lol -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Master Visual Studio, SharePoint, SQL,
Re: [E-devel] eo and efl
On Sat, 29 Dec 2012 11:48:36 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Fri, 28 Dec 2012 22:31:18 + Michael Blumenkrantz michael.blumenkra...@gmail.com said: On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi lucas.demar...@profusion.mobi wrote: Hey! I'd like to start a discussion about eo and its usage in EFL. I got very frustrated on how it was merged regardless the opinion of the other EFL developers. IMO it could make some sense in elementary, but not in the core like ecore, evas, edje. Asking around I discovered I was not the only one rather the opposite - everyone I asked hates how it's done. Recently I had to review some patches to elementary, adding the systray support. My eyes were bleeding. I will enlist here some reasons in no particular order. Surely there are more... others are welcome to fill them here. - We replaced the function calls with eo_do(func()). Now, take an application and imagine all ecore_*, evas_*, elm_* functions replaced with eo_do(func()). This is not just ugly... it's impractical to use. - eo_do() is the userspace incarnation of ioctl() - search on LKML to see how it's hated there. it does make me consider entering one of those code obfuscation contests... - *every* function in a backtrace comes with the _eo_dov_internal()/_eo_op_internal() companion - besides polluting the bt, for sure they have a cost. And I saw no benchmarks on mailing list after the addition of eo. One might think that since *I* am complaining, *I* should provide them, but I think it's exactly the opposite - people who added this thing should make sure it's now the same or better than it was before. backtraces with eo are the reason I don't see myself ever switching to the 1.8 branch. as for benchmarks, I saw some supposed numbers thrown around during early eo development which claimed that it was slower, but not that much slower, and worth it for the gains - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. - why is it any better than the smart object we had all these years? Why not improve that instead of replacing with eo? - run elementary_test with EINA_LOG_LEVELS=5 and see the construction/destruction party not to mention the spam just from running e - Despite raster arguing this is not an API break, I strongly believe it is. It broke compilation of lots of c++ applications (I'll not repeat myself here... in the mailing list there are my other arguments why it is an api breakage) My opinion is to revert the whole thing, but I'm sure this would be a major task after the surgery to put it in was made. I'd at least like the people responsible for it to answer the points above, and people who like me think this is all crap to step up and say so. Lucas De Marchi depressing though it may be to think about, I have to agree with your points. I'm not saying it needs to be reverted, but I don't see any benefit to keeping it unless the goal was to reduce my commits to the afflicted areas to near zero. while it's impressive that all of the eo stuff was added with relatively little breakage (as opposed to my expectations), the idea of having to learn what is essentially a different programming language in order to work on efl internals again in trunk is really demotivating. maybe I'll become the kwo of the 1.7 branch? fair enough. it's a change. it's not a change i wanted. it's a change that was NEEDED. needed because once you go beyond the scope of us few efl devs, you hit a wall of developers who can take our api - documented or not, with examples or not, and then just fall over tehmselves and end up wasting our time by the bucket load in the process. you never experienced it so you never felt or sw the pain. you were insulated. this change is some of that insualtion not able to continue and something has to leak. it has to give. if this demotivates you, then i guess, so be it. continuing as we were would have demotivated me to the point of giving up. it also *HAS* deotivated a dozen+ other people. so we lose either way. without eo peolpe doing bindings do them the hard way - forever. eo provides for introspection and documentation. Ah, so I'd have to redo the Lua bindings to use eo soon? That will at least get my hands dirty with it, then I can give a proper whinge, er I mean opinion. Introspection is good, I love introspection. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Master
Re: [E-devel] eo and efl
On Sat, 29 Dec 2012 11:28:29 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Fri, 28 Dec 2012 20:17:14 -0200 Lucas De Marchi lucas.demar...@profusion.mobi said: - If we really needed this level of OO in ecore, evas, edje, we'd be better off using C++ or inventing our own language to fit our needs instead of doing what we are doing now. c++ would be a sledgehammer solution and comes with lots of downsides of its own. other languages too. the fact is we can slide eo in without rewriting in another language. the only thing really missing is namespacing. EFL trying to do proper OO in C rather than C++ is one of the reasons I like working with EFL. C++ and C# might be the flavour of the decade, but it's too esay to write insane code in them, not to mention the other downsides that raster also did not mention. B-) A lot of my planned virtual world work is ripping out insane C++ and C# code and replacing it with sane C code. Coz almost all of the existing code is insane C++ and C#. Yes, it's possible to write sane C++ and C#, but judging by the quality of most of the code I have seen, it must be really hard to do so, especially in very large multi programmer projects. It's also possible to write insane C code, it just tends to bite you harder when you do, so you may actually notice and fix it. :-P -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
