On Sun, 9 Apr 2017 23:25:39 -0700 Cedric BAIL <cedric.b...@free.fr> said:
> On Sun, Apr 9, 2017 at 7:51 PM, Gustavo Sverzut Barbieri > <barbi...@gmail.com> wrote: > > On Sun, Apr 9, 2017 at 9:38 PM, Simon Lees <sfl...@suse.de> wrote: > >> On 04/10/2017 12:39 AM, Gustavo Sverzut Barbieri wrote: > >>> Which brings me to my last point: we should adopt and use for REAL a > >>> binding. You all know my personal preference is Python, but in 11 > >>> years I couldn't convince people to like it... so whatever people > >>> like, let's pick one language and use it as much as possible where > >>> appropriate (you're not rewriting the core of Evas in it...). It seems > >>> Lua is strong contender, and is very efficient, small and already a > >>> hard dependency... our docs are being generated by a lua script, > >>> etc... > >>> > >> openSUSE ships atleast 4-5 applications using the python bindings and > >> could probably ship a few others from bodhi. (We don't at the moment as > >> they don't have a proper build system and I haven't had the time to port > >> them too one). I personally also prefer the python bindings and have > >> used them in the past. > > > > I'm a python guy, wrote the initial python efl... I wrote big software > > using that (Canola 2.0 if people remember of that) and tried to push > > them as E modules... never sticks, particularly Rasterman never liked > > it, thus a major developer who would never ever touch it -- and this > > defeats the purpose. > > > > Lua isn't bad, and as it's required to build and during efl's use, we > > can stick with that. Like making it zero-cost/effort to enable lua > > scripting in every application, reducing the pain to write simple > > stuff like basic configurations. > > I like the idea of having a zero-cost/effort to add scripting support > in any EFL application. I don't know yet how easily we can do that. I technically... thats exactly why q66 has done libelua.so... :) it's so the elua binary launcher can be used without putting al the code in there. it's so eventually "bob" could easily load lua too etc. etc. - basically provide a higher level luajit + efl binding setup to allow just this. it hasn't been exercized beyond the elua binary right now which is used to generate al our eo based docs... so it does work in that sense... :) > guess that maybe some of the binding should provide a library as part > of EFL to make it easy to do integrate them. Something doing > initialization, registering object, loading a script and executing one > for some amount of time. elua :) > I am also not sure about lua at all here. I know we are focusing > mostly on performance, but if we really care about increasing our > developers base and making it easier, isn't JS the winner in that > space ? Isn't it over already for choosing the scripting language ? from a performance and size point of view lua is the biggest winner. from a popularity point of view js is the biggest winner. it depends how much you expect people to do in scripting. the more you expect them to write in it, the more size, performance etc. will matter. the less they do, the less it matters. if we take gustavo's point about "using high level languages more" then the implication is to use them more and more and more. thus it matters. personally i prefer js a little more than lua from a language point of view... but because of performance etc. imho lua is the winner. if someone came up with a js library like luajit that was about the same size and performance i wouldn't hesitate to jump behind js. one possible option is to jump behind the transpiler bandwagon. what about writing a js -> lua transpiler? this should be not that hard given the incredible similarity in the 2 languages. you can then write in lua or in js. just you need a compile step for js. perhaps we should also have a compile step for lua anyway? at least minify it for faster parsing etc....? > > Take terminology as an example, while the core VT handling is > > something I'd keep in C, all of those settings, tab management and > > even mini view layout could easily be Lua. Of course allowing the > > terminal handling itself to be extensible in lua would be awesome, > > like plugins to do search, highlight and preview... even allowing > > tyls/tycat/... kind of escape extension to be handled to the plugin. > > > > Extra is likely an app that could be fully written in the high level > > language, maybe Rage is in that front as well. While Ephoto could use > > it for everything but the image filtering (actually that one would be > > better suited to some kind of filtering abstraction that would execute > > in CPU or GPU). > > Here is a slightly different idea. Instead of adding scripting to all > our existing application, what if we extend extra to also deliver > sandboxed JS/Lua applications. It could be very neat if we could on > this sandboxed application contribute patch on it in almost one click. > I think this will solve one of the core limitation of working on > native technology, the long cycle between when you are done writing a > patch and the time your users see it and also the ability for users to > easily contribute to it. this is where i have been thinking our lua support specifically would come out best. because efl ships with a guaranteed set of lua support WITH a lua exector (elua) then we have a full guarantee that any app written in lua will work anywhere efl it installed. this means we don't have to solve all sorts of extra problems - simply installation of such apps and to some extend mrk solved this as apps are installed in ~/Applications and it manages symlinks to their binaries to ~/Applications/.bin/ and so on so they appear in your application menus. > I know that GNOME is going on the very hard road for this and trying > to make sandboxed application using systemd and all the > infrastructure. It would be neat to support this environment in > Enlightenment, but I don't think we have the man power to do so. > Sandboxing JS and Lua, together with some sort of application delivery > seems much more doable with the team we have, but I may be wrong. i think elua can provide the universal execution solution and also some sandboxing. maybe another binary like elua_sandboxed that would lock down the environment before launching any lua code. we can start with it having no sandbox at all and overt time improving it. at least take the install-side ideas from marrakesh for getting applications installed and then an online repo that can be uploaded to, downloaded from etc. when i find some time i was going to write a miniature/simple http server using efl.net and then merge in a lot of mrk from that. all of this of course is dependent on eo+interfaces being stable and usable by developers. once it is, then elua comes along for the ride. js should work if node.js is installed and efl support for it in bindings is enabled at compile time. native binaries are possible but more work. > -- > Cedric BAIL > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
