On Wed, 8 Jan 2014 09:20:04 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> On Tue, 7 Jan 2014 21:42:47 +0100 Davide Andreoli > <d...@gurumeditation.it> said: > > > 2014/1/7 Cedric BAIL <cedric.b...@free.fr> > > > > > On Tue, Jan 7, 2014 at 1:27 AM, Tom Hacohen > > > <tom.haco...@samsung.com> wrote: > > > > On 06/01/14 04:25, Cedric BAIL wrote: > > > >> As we move forward with Eo and Eolian, we will generate a part > > > >> of our code automatically at compile time (some .c and .h). We > > > >> also by now require a C++ compiler (for ephysics) and Lua for > > > >> Edje. So I am thinking it is starting to make sense to plan > > > >> the generation of those bindings at the compile time of EFL > > > >> to, instead of relying on another stage where will would > > > >> generate those. > > > > > > > > I disagree. > > > > > > > > First of all that "another stage" is done by packagers, and > > > > since packagers will split those anyway (more work), it doesn't > > > > save anyone any work, but might actually increase the work for > > > > packagers (now having to remove the C++ libs and headers). > > > > > > There is no such think as a C++ library and I don't see why they > > > would specifically split away C++ header out of EFL devel > > > package. You would have to enlighten me on how you expect EFL to > > > be packaged. I am arguing that it is a bad idea to split EFL more > > > than just a devel package and the rest. > > > > > > >> Benefit would be that we do provide support for 3 languages > > > >> out of the box when you install the developers package of EFL. > > > >> We are not adding a new set of dependency as they are already > > > >> in. Also we can just parse Eolian file once and generate all > > > >> output code at the same time which will be more efficient and > > > >> will generate bindings faster than if we have to do that > > > >> outside of EFL. > > > > > > > > This is not for free. > > > > > > > Indeed is not for free, apart from the rough generation of the > > binding there are lots > > of collateral work to do for each lang: documentation, unittests, > > examples, etc > > Without counting the post maintenance: testing, helping users, > > writing tutorials, etc. > > IMO supporting lua just because we depend on it yet is quite crazy > > (and a huge work). > > > > Speaking about python: the generation step do not require nothing > > at all, If I > > understand correctly how eolian will work: Eolian will write all > > the Cython files > > more or less as they are now, thus also generating the setup.py > > script. The dependencies comes when you want to compile and install > > the generated bindings, at that point you will need the python dev > > package and cython installed. > > > > I'm right? is this the intended workflow? > > 1. eolian (when compiling efl) will generate the bindings source > > code 2. the user then go in the "py-binds" folder and run "python > > setup.py install" > > > > or we want the bindings to be installed automatically on "make > > install" ? The question is: eolian just generate or also install > > the bindings? > > > > > > For sure me and kuuko will work on the python side of eolian, so > > please think at it from the start, surly under an > > --enable-python-bindings flag, just > > provide us with an empty shell in eolian and soon we will start to > > work on. > > > > davemds > > i think that right now lua (and python and ruby et al) are just > distractions. let's re-focus back on the c++ bindings. these: > > 1. don't require any new build tools we don't already use/need > 2. don't require any extra libraries we don't already need/use > 3. they will be direct 1:1 mappings of eo classes to c++ classes - > unless the c+ > + bindings generator is broken, they should "just work" (tm). since it > generates generically once shown to work it should be minimal to zero > work to keep around as it is close to the c in terms of how it works, > binds etc. 4. the ONLY thing that is not a 1:1 mapping would be the > eina datatype mappings to stdc++ types so when we return a list then > it looks like a stdc++ list to the caller. that's manually done. > again - once it works, we're good. > > since we can just build the c++ bindings while building efl (if off > by default --enable it) then it's basically "free". the OTHER stuff > is not free - at least not right now. the lua thing is currently > pie-in-the-sky stuff because we use lua 5.1/5.2 but we're TALKING > luajit - and we aren't there. someone would need to build a basic > runtime (ala elev8) to house the app to begin with and only THEN can > we talk bindings. being able to generate bindings (selectively) for > things like bob (also pie-in-the-sky) will cut that project down to a > fairly small amount of work vs having to bind efl manually. Now that I'm healthy again, heatwave is over, and silly season is over, and I have my Mac, this is one of the things I'll be getting stuck into now. More specifically, I plan on spending a lot of time this year on my virtual world stuff, which includes plans to bring LuaJIT to Edje Lua soonish. My virtual world stuff already includes an AST to Lua generation stage, which I think might fit into these plans of E. The pie-in-the-sky Bob plans will be kept in mind and probably looked at soon to. Since as far as EFL is concerned, I'm mainly concerned with Edje Lua, it's not a distraction for me. B-) In case you where wondering, my lifes goal is to produce a great virtual world system built on EFL. That was held back until Christmas coz I needed to make Linux, Mac, and Windows versions to suit my users, and I didn't have any Mac development resources. Bought a Mac Mini for Christmas, but the silly things can't deal with 35 degree C plus temperatures, and we had a heat wave since before Christmas, where it got to 42. Cool enough now to run the Mac. lol -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
