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/) which wants to be my executable. How can I just use my already installed luajit? Why would you even encourage a executable for this?
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.
In lua it is customary to bring along your own main loop.
People often start with one based on select, but later move to libevent, libev, cqueues, luv (libuv), glib or others.
> for lua there IS not native mainloop
Neither is there for C.
> as there is no native lua runtime (beyond a sample lua cmdline)
The 'sample' lua application is quite often used as a runtime; if your library can't be used from it, it won't be useful for the majority of developers.
> we provide one (elua) that will load in the bindings stubs for you and thus work
In elua you still have to load in the bindings yourself (via require).
> 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.)
I have no idea how this is related. lua already has tools to pack resources into one executable (e.g. srlua). but you can use any tool/method you want. This doesn't dictate the main loop used in any way.
> how do you run things "by default" and know it will work and which one will be installed?
you just use #!/usr/bin/env lua. Which will pick up whatever the user/distro has picked (e.g. a user might use debian update-alternatives). If you need a particular version of lua, use `#!/usr/bin/env lua5.1` which is the generally accepted shebang.
And that is what we provide - yes the toolkit is built around the mainloop we provide. It's a core design concept. It's a necessary thing to have a working UI to drive I/O. Trying to avoid a mainloop is just an order of magnitude more painful and leads to pretty bad design. UI updates are tied in great detail to the mainloop where they actually time themselves to vsync updates invisibly to the programmer for example.
> Neither is there for C.
Yes, and thus a toolkit brings one along. This is the case for sure for GTK+ - that mainloop is glib. That's how this works. Trying to avoid a mainloop or just choose whatever one you like is also like asking "well I want to use GTK+ for this widget and Qt for this one, and maybe EFL for this other one... in my window". If you jump through enough hoops and create enough ugliness it might be possible, BUT it comes at a cost. Trying to avoid this pushes everyone into the loweest common denominator design which basically means "assume X11, a window and draw commands and you call a 'draw me' function, then have more functions to push in events etc." ... this gets insanely complex once you start dealing with sizing, layout logic which differ, and not to mention you just screwed the pooch on deferred rendering, trying to to real acceleration e.g. via OpenGL because this is no longer even close to optimal etc. ... and mainloops are similar (though simpler). you can squeeze them together with some effort but trying to design without one and "well go bring your own" just leads to incredibly horrible API as well as overhead for the developer.
> The 'sample' lua application is quite often used as a runtime; if your library can't be used from it, it won't be useful for the majority of developers.
that's not of much if any concern to us as we provide a runtime already.
> In elua you still have to load in the bindings yourself (via require).
that will change as its simply boilerplate someone shouldn't need to go from zero to working app.
> I have no idea how this is related. lua already has tools to pack resources into one executable (e.g. srlua). but you can use any tool/method you want. This doesn't dictate the main loop used in any way.
If your source and resources are packed into a single file then the executor needs to be able to read from that file and unpack stuff from it FIRST before a single line of any lua code is run. it has nothing to do with mainloop etc. - it has to do with features existing before any lua code is run.
> you just use #!/usr/bin/env lua. Which will pick up whatever the user/distro has picked (e.g. a user might use debian update-alternatives). If you need a particular version of lua, use `#!/usr/bin/env lua5.1` which is the generally accepted shebang.
perhaps ONLY on debian... because on arch i can have both lua and luajit installed and /usr/bin/lua is PUC lua ALWAYS and /user/bin/luajit is from luajit - always. env will not work here as the command is actually totally different.
No you don't need to abstract the X11 calls. What you should expose is an fd+pollmask (or collection of them) for the program to poll (+ timeout if you need it), and a function to call to make progress.
The latter you already have in C in ecore: `ecore_main_loop_iterate`
The former is a bit trickier with EFL, I guess you could create something with `ecore_main_loop_select_func_set`, but the API inside out: you really want to be able do the replacement select from outside of `ecore_main_loop_iterate`. I haven't read into the implementation to see if this is already possible.
> that's not of much if any concern to us as we provide a runtime already.
I don't want your runtime, I just want your GUI functions. I need you to integrate with my existing runtime.
> If your source and resources are packed into a single file then the executor needs to be able to read from that file and unpack stuff from it FIRST before a single line of any lua code is run. it has nothing to do with mainloop etc. - it has to do with features existing before any lua code is run.
Why? the lua code itself can do the unpacking if it wants to. There are tools around to do this. But I don't think we need to continue this subthread.
