Daniel Zaoui <[email protected]> writes: > Yo Bro, >
Please find my comments inline. > Before you see my comments, just to tell you we moved our code into the > jackdanielz/eolian branch into EFL. > If you still want to use the Eolian repo, just check you are on one of > my commits "Merge...". Otherwise, it is not sure .eo files correspond to > the lexer. > > On 02/18/2014 08:03 PM, Savio Sena wrote: >> Daniel Zaoui <[email protected]> writes: >> >>> Hi Savio, >>> >> Hello Daniel, >> >>> Thank you for your update. >>> >>> However (because there must always be a "however" in a mail), I have >>> some issues: >> I'd make good use of more information here. What's your distro? Which >> command line you used? Do you have eolian installed in your prefix? >> Before answering though please read through. Perhaps you'll be able >> to solve it. > > I am using Ubuntu 13.10 (updated). > I used the script you provided. > Eolian is installed in /opt/e17 (don't ask why e17, historical reason :-)). > >> >>> - Building: >>> - cmake fails on "get_filename_component unknown component >>> DIRECTORY". I need to change to "set(EOLIAN_LIBDIR /opt/e17/lib)" to >>> make it work. >> Hmm. That means I have to improve the error messages. I can't tell >> precisely what's wrong. My guess is that cmake is not finding >> "eolian.pc", which makes "find_package(Eolian REQUIRED)" fail. > > Let's check next week together. > >> >>> - Building colourable fails on "/bin/sh: 1: Syntax error: Bad fd >>> number". I need to make VERBOSE=1 and then execute the line to make it >>> work well. Is there another option? >> One minor note: you can set verbose flag through build.sh as well: >> ./build.sh eo1 verbose ${YOURPREFIX} >> But that is certainly caused by the above error. No idea why VERBOSE=1 >> fixed it though. > > I used VERBOSE=1 to see the command line, and then copy/pasted and > executed it manually. > >> >>> - The build takes a lot of time imo. Is there a good reason why? >> Yes, there is. Ecxx makes massive use of C++ templates. That makes >> compilation tough for the compiler. I tried to modularize the code to >> require less memory, but I can't help saving processing effort. In other >> hand after compiling the code is pretty lean and fast. ;-) > > Imo, this is a big issue. Since Ecxx is supposed to be integrated inside > EFL/Eolian and Eolian is needed as generator of most of the files, I > don't think it will be parallelizable during compilation and so will > become a bottleneck of 2.5 minutes. And this is bad, really bad. > > I still don't understand why C++ is needed to generate C++. C can make > the printer job easily and faster (yes, faster than 2.5 minutes :P). But > we will have time to discuss about this next week ;-) > I understand your point, still I don't find it a major issue. There's no need to compile the c++ generator every time. For the development cycle for example we could rely on a ./configure flag to enable Ecxx only when explicitly required -- few developers will actually use it on a regular basis. In case of a release version for example we could ship the generated code along with everything else. Also, in my opinion it's unlikely that we can write a better program in C in this case. Karma does an awesome job in terms of syntax, maintainance and performance. It's concise, lean, easy to write, easy to read (when you get used to it of course, like most of the things). Dropping it over a code that simply compiles faster but it's harder to read and maintain it's probably a bad idea. What do you think? >> >>> /[ 16%] [ 50%] [ 50%] [ 66%] Building CXX object >>> src/lib/CMakeFiles/ecxx-generator.dir/eo_class_detail_generator.cc.o// >>> //Building CXX object >>> src/lib/CMakeFiles/ecxx-generator.dir/eo_class_generator.cc.o// >>> //Building CXX object >>> src/lib/CMakeFiles/ecxx-generator.dir/eo_class_event_generator.cc.o// >>> //Building CXX object >>> src/lib/CMakeFiles/ecxx-generator.dir/arguments_generator.cc.o// >>> //[ 83%] Building CXX object >>> src/lib/CMakeFiles/ecxx-generator.dir/eo_class_operations_generator.cc.o// >>> //[100%] Building CXX object >>> src/lib/CMakeFiles/ecxx-generator.dir/eo_version_generator.cc.o// >>> //Linking CXX static library libecxx-generator.a// >>> //[100%] Built target ecxx-generator// >>> // >>> //real 0m56.008s// >>> //user 2m30.616s// >>> //sys 0m6.168s// >>> / >>> - generated .hh file: >>> - bad arguments names: why don't you use Eolian to retrieve the >>> parameter names? >> Only because it's not necessary. It doesn't add much. Why would you read >> the generated code after all? > > Of course, it is. You don't want IDEs to show you APIs with a0, a1... > but with good params names, docs (Doxygen)... > Hmm. That makes sense. I had not considered this case. I will do it then. It may take a while -- probably won't be ready for our meeting next week --, but I won't forget. >> >>> - in extension_inheritance, why for example colour_get is taking >>> int* instead of returning int? >>> >> That was not supposed to be there, you're correct. Thanks. I'll fix it. > > Good. > This one I'll handle right away. Probably today. I'm planning to sync Ecxx with the latest version of Eolian as well, so you can expect updates soon. >> >>> Thank you for your support >> Before I go :) Let me show how I installed Eolian and Ecxx. Perhaps you >> can reproduce my good results there: > > I will check it soon. Please let me know your results. I think it's the eolian part that is missing. Probably the 'cmake -DCMAKE_INSTALL_PREFIX=/opt/foo .. && make all install' thing. That will copy 'eolian.pc' to the right location. Kind regards. -- Savio Sena <[email protected]> ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
