On Sat, 15 Apr 2017 11:10:32 +0930 Simon Lees <sfl...@suse.de> said: > > > On 04/13/2017 09:44 AM, Carsten Haitzler (The Rasterman) wrote: > > On Tue, 11 Apr 2017 09:41:06 -0700 Cedric BAIL <cedric.b...@free.fr> said: > > > >> On Tue, Apr 11, 2017 at 2:52 AM, Carsten Haitzler <ras...@rasterman.com> > >> wrote: > >>> On Tue, 11 Apr 2017 18:58:58 +0930 Simon Lees <sfl...@suse.de> said: > >>>> On 04/11/2017 04:19 PM, Carsten Haitzler (The Rasterman) wrote: > >>>>> On Mon, 10 Apr 2017 12:01:49 -0300 Gustavo Sverzut Barbieri > >>>>> <barbi...@gmail.com> said: > >>>>>> 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 > >>>>>>> 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. > >>>>> > >>>> > >>>> I'll be controversial and say that for many Desktop UI applications and > >>>> probably for a lot of smartphone ones as well performance really doesn't > >>>> matter that much, its not like were running these things on a 386, So I > >>>> guess sometimes less performant languages have other benefits which is > >>>> why people use them. > >>> > >>> then why does android precompile java apps to native code on installation > >>> now as opposed to just keep interpreting? :) > >> > >> No clue of what this guys are doing, but I can tell you for sure, you > >> will be fine writing EFL application in JS. For a reminder, EFL with a > >> JS binding without any JIT run fine for doing 2D games on a MIPS at > >> 200Mhz with no GPU. So speed is absolutely not necessary for the large > >> majority of application with EFL as a toolkit (Not talking bob here). > >> I think that if we are to choose a preferred binding, we should go > >> with what bring most developers in. > > > > then why did google bother with v8? why did firefox do tracemonkey? if js > > interpreted is fast enough? remember that js in a web page will be similar > > to js + efl - the web engine is doing the heavy lifting for ui, rendering > > and layout... > > > > my point is ... it is NOT good enough. not in the general case. not when > > performance directly relates to battery life. if you go "well today's cpu's > > can run that ok" sure.. but then your battery life lowers by 5%. 10%, > > 20%... ? > > > > there is a solution that gets us both speed and simplicity - luajit. lua > > isn't an unknown language. it would be possible to write a js -> lua > > transpiler and thus get the best of all worlds using luajit as an execution > > engine. > > > Yes but can we finish the eo project before we start the next project > please :-P
well gustavo did begin this with the premise that this is "post eo/interfaces" -- ------------- 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
