On 02/20/2014 11:06 AM, Tom Hacohen wrote:
> On 19/02/14 16:28, sa...@expertisesolutions.com.br wrote:
>> Daniel Zaoui <daniel.za...@samsung.com> 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 <daniel.za...@samsung.com> 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?
> I lack some context, so le me know if I'm wrong in my understanding, but
> are you thinking about putting the C++ generator in the same executable
> as the C eolian? I see no point in that, you can just create another
> executable (in C++ or whatever language you see fit), and use the eolian
> lib API.
I don't think it matters if it is integrated into Eolian or not, the
fact is that it takes a lot of time to compile a generator (we are
speaking of about 2000 lines of code) that could be written in a
language already known by EFL people (C, LUA or whatever).
So people will have to get used to that new language, we will have a
boost dependency in EFL (yes, in EFL with some flag to enable the
generation of C++ files, as I understood from Cedric)...
> --
> Tom.
>
>
>
> ------------------------------------------------------------------------------
> 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
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
------------------------------------------------------------------------------
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
