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 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. >
Ruby binding is a 1:1 + a ruby object layer (elementary,evas,ecore done). As ruby is more a language spec than an implementation, the advantage of this approche is that you are not thight to the internals of a specific implementation. There is a third party lib (ffi bound to libffi) which provides the mechanisms, so if the language implemetation supports it, your binding works. > > 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. > Ruby binding follows the 1.7.4 API, anv covers not far from 100% of evas, ecore, e_dbus, edje, eet, efreet, eio, elementary, embryo, ethumb, eina_list, eina_hash, eina_file. eeze and emotion will quickly follow. (as a 1:1 binding). About eo, I haven't thought much about how to go further with the ruby binding, but I'm a little worried for now. > > 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 -- Jérémy Zurcher av General Guisan 49 1400 Yverdon-les-bains +41 (0) 79 599 84 27 ------------------------------------------------------------------------------ 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
