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 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. > 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". Seriously ? You want to rewrite EFL in Vala ? Wasn't it Go or Python last time ? -- 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
