On 04/13/2017 09:44 AM, Carsten Haitzler (The Rasterman) wrote: > On Tue, 11 Apr 2017 09:41:06 -0700 Cedric BAIL <[email protected]> said: > >> On Tue, Apr 11, 2017 at 2:52 AM, Carsten Haitzler <[email protected]> >> wrote: >>> On Tue, 11 Apr 2017 18:58:58 +0930 Simon Lees <[email protected]> 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 >>>>> <[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 >>>>>>> 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
-- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
