On Mon, 10 Apr 2017 12:01:49 -0300 Gustavo Sverzut Barbieri <[email protected]> said:
> On Mon, Apr 10, 2017 at 4:50 AM, Carsten Haitzler <[email protected]> > wrote: > > On Sun, 9 Apr 2017 23:25:39 -0700 Cedric BAIL <[email protected]> said: > > > >> On Sun, Apr 9, 2017 at 7:51 PM, Gustavo Sverzut Barbieri > >> <[email protected]> wrote: > >> > On Sun, Apr 9, 2017 at 9:38 PM, Simon Lees <[email protected]> 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. jerryscript is interpreted only - no jit, so it's going to have a fairly big performance hit vs something jitted. if the point is to write more and more in such a language you want it to be as performant as possible. it can be more performant with a jit... so you'd want that. > also be warned about js... not sure if you used it for real, but it's used it in html for a few things a while ago... a long while ago. not really written lots of it - just glue code or "onclicked=function ..." stuff. > 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. dunno but as i have said - i lean to lua due to luajit really solving basically all the core issues other than "popularity". i've never been one to make decisions just because it's popular... :) i was just saying that transpiling can give people the ability to write in js and not have to use lua... :) > [...] > > 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. well i'm waiting to see... but once i find the time i'll go that way if something else is around... i wont put it into efl - it'll bake it into app code so it could be replaced later... but i'd like to make a start at moving protocol to http to deal with firewalls and proxy-compulsory environments. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
