6 ms·

well it's a framework like Qt is... :) or like GTK+ and glib and then some. so if these were acceptable for bindings if they were maintained/up to date then EFL

well it's a framework like Qt is... :) or like GTK+ and glib and then some. so if these were acceptable for bindings if they were maintained/up to date then EFL would be. But yeah - we bound to LuaJIT because of performance and FFI. Technically bindings could generate C code for PUC Lua too. We generate C++ for v8 for JS, so it's possible but not done. My point was that we're making bindings a first class citizen part of development of the core. maybe this will fill in the gaps others have tried to fill before?

daurnimator 10y ago
> well it's a framework like Qt is... :) or like GTK+ and glib and then some. so if these were acceptable for bindings if they were maintained/up to date then EFL would be. Languages want a something that can act as a library; not something that completely dictates the structure of your program. e.g. you must be able to specify your own main loop. Glib does allow this, however the gobject introspection for it is completely broken. I haven't looked into it for Qt for a while
- rasterman 10y ago
  node.js insists on its own mainloop. python is agnostic. efl already integrates with node's libuv usage and glib mainloop. really gtk requires a glib mainloop. you make glib integrate/sit on top of something elses and efl did the same thing.
  - daurnimator 10y ago
    You're saying you don't make efl run on top of your own mainloop, but instead integrate with ecore? Isn't ecore part of efl anyway? Either way, is the mainloop-integration part exposed in the bindings? `grep -r main_loop_iter /usr/share/elua` doesn't show me any results. I just installed 'efl' (on archlinux), and I get a binary "elua" (which is a conflicting name with the famous project http://www.eluaproject.net/ http://www.eluaproject.net/) which wants to be my executable. How can I just use my already installed luajit? Why would you even encourage a executable for this?
    - rasterman 10y ago
      well we already did the integration. it doesn't need exposing. it's meant to be handled by the bindings for that runtime environment specifically or is just always available. so it merges currently with glib mainloop and with libuv so if you run the ecore mainloop you ALSO have (optionally as long as efl is compiled with these) a glib and a libuv loop too merged together as one, so they all are then compatible and work at the same time. yes - it requires the app spin up the ecore mainloop (it actually is the efl.loop now) instead of another, but existing code that uses the 'native mainloop' for that runtime will continue to happily work just as it was working before in that runtime env, but as lua never provided a mainloop, then we're it along with glib if you want and/or libuv. the integration is done down in the c code for the efl loop. for lua there IS not native mainloop as there is no native lua runtime (beyond a sample lua cmdline), and by this i contrast it to something like node.js. we provide one (elua) that will load in the bindings stubs for you and thus work. we do this because lua itself unlike something like node.js or python doesn't push the idea of "a single lua executable to run all lua runtimes". it has demo/sample/test executors, but it is built as a library primarily to then be embedded into another runtime. we happen to provide a guaranteed runtime binary too. there are very good reasons for this for the future, like being able to package up applications into archives (like .apk for android, .jar or java etc.) as we already have a whole archive library (eet) that handles random access read (and decompress), so this would allow for lua apps to be shipped as single file archives with all script AND data files (images, theme data, videos, icons and more) in a single file just dropped into a directory with no extra dependencies or tools needed. to do this we need something like elua. our whole intent is to actually become a portable cross-platform toolkit where you do not need external plugins, binaries, libraries and can build a portable application that "just works" on multiple OS's without needing to instruct people on how to install 3rd party dependencies. also so far we've supported both luajit and puc lua (and intend to drop puc lua because of ffi and a few other niggles) so this is a big problem as to which executable then gets used? different names. lua va luajit. how do you run things "by default" and know it will work and which one will be installed? part of our build uses elua and lua scripts to generate documentation so how could we run our doc generator when we don't know what executor is there on the host? we'd have to add more detection and have file.lua.in files where #!/bin/whatever is replaced with the correct lua etc. ... not pretty where now #!/bin/env elua will do fine.

daurnimator 10y ago

> well it's a framework like Qt is... :) or like GTK+ and glib and then some. so if these were acceptable for bindings if they were maintained/up to date then EFL would be. Languages want a something that can act as a library; not something that completely dictates the structure of your program. e.g. you must be able to specify your own main loop. Glib does allow this, however the gobject introspection for it is completely broken. I haven't looked into it for Qt for a while

rasterman 10y ago
node.js insists on its own mainloop. python is agnostic. efl already integrates with node's libuv usage and glib mainloop. really gtk requires a glib mainloop. you make glib integrate/sit on top of something elses and efl did the same thing.
- daurnimator 10y ago
  You're saying you don't make efl run on top of your own mainloop, but instead integrate with ecore? Isn't ecore part of efl anyway? Either way, is the mainloop-integration part exposed in the bindings? `grep -r main_loop_iter /usr/share/elua` doesn't show me any results. I just installed 'efl' (on archlinux), and I get a binary "elua" (which is a conflicting name with the famous project http://www.eluaproject.net/ http://www.eluaproject.net/) which wants to be my executable. How can I just use my already installed luajit? Why would you even encourage a executable for this?
  - rasterman 10y ago
    well we already did the integration. it doesn't need exposing. it's meant to be handled by the bindings for that runtime environment specifically or is just always available. so it merges currently with glib mainloop and with libuv so if you run the ecore mainloop you ALSO have (optionally as long as efl is compiled with these) a glib and a libuv loop too merged together as one, so they all are then compatible and work at the same time. yes - it requires the app spin up the ecore mainloop (it actually is the efl.loop now) instead of another, but existing code that uses the 'native mainloop' for that runtime will continue to happily work just as it was working before in that runtime env, but as lua never provided a mainloop, then we're it along with glib if you want and/or libuv. the integration is done down in the c code for the efl loop. for lua there IS not native mainloop as there is no native lua runtime (beyond a sample lua cmdline), and by this i contrast it to something like node.js. we provide one (elua) that will load in the bindings stubs for you and thus work. we do this because lua itself unlike something like node.js or python doesn't push the idea of "a single lua executable to run all lua runtimes". it has demo/sample/test executors, but it is built as a library primarily to then be embedded into another runtime. we happen to provide a guaranteed runtime binary too. there are very good reasons for this for the future, like being able to package up applications into archives (like .apk for android, .jar or java etc.) as we already have a whole archive library (eet) that handles random access read (and decompress), so this would allow for lua apps to be shipped as single file archives with all script AND data files (images, theme data, videos, icons and more) in a single file just dropped into a directory with no extra dependencies or tools needed. to do this we need something like elua. our whole intent is to actually become a portable cross-platform toolkit where you do not need external plugins, binaries, libraries and can build a portable application that "just works" on multiple OS's without needing to instruct people on how to install 3rd party dependencies. also so far we've supported both luajit and puc lua (and intend to drop puc lua because of ffi and a few other niggles) so this is a big problem as to which executable then gets used? different names. lua va luajit. how do you run things "by default" and know it will work and which one will be installed? part of our build uses elua and lua scripts to generate documentation so how could we run our doc generator when we don't know what executor is there on the host? we'd have to add more detection and have file.lua.in files where #!/bin/whatever is replaced with the correct lua etc. ... not pretty where now #!/bin/env elua will do fine.