On Mon, Apr 10, 2017 at 4:50 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > 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....?
isn't jerryscript good enough? Seems pretty small, not sure if they're focusing on efficiency as much as ram/disk. also be warned about js... not sure if you used it for real, but it's hardly usable "as is", most people are used to the nice extensions provided by frameworks that will monkeypatch even the basic classes... if you get a self-claimed "JS developer" and ask him to iterate a dictionary they'll like fail without the "foreach()" helpers. [...] > 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. don't go that route now, Flavio Ceolin was creating a efl.net.server.http using libmicrohttp... would be much simpler for you to proceed. -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ 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
