openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan iversen <jancasacon...@gmail.com>
Subject Re: [early codereview / check for standards] genLang in l10ntools
Date Tue, 06 Nov 2012 18:56:10 GMT
I am not a deep makefile specialist, but the last project we worked on, had
lines similar to what I wrote, and the process was just started once for
all files on the line.

in our case I would say:
   dMake genLang

And that should cause dmake to start "genLang  -m<module name>  -t<target
dir>  src1.hrc src2.xcd ...."

I will just check with my former colleagues, maybe they did something more.

I will write your list of variable names on my drawboard and try to keep it.

Have a nice evening.
Jan.


On 6 November 2012 19:33, Andre Fischer <awf.aoo@gmail.com> wrote:

> On 11/6/12 5:59 PM, jan iversen wrote:
>
>> @andre:
>>
>> I just saw one line in your mail, that I forgot to respond to....you look
>> for the interesting part of the code, the file tree scanner.
>>
>> There are no tree scanning with the new concept, it is done by the
>> makefile.
>>
>> Each makefile (or build.lst) is extended with something like:
>>
>> genLang: src1.hrc src2.xcd ....
>>          genLang  -m<module name>  -t<target dir>  $*
>>
>> Thereby each single developer decides which files get scanned, and build
>> get rid of this big tree scanning.
>>
>
> So collecting the files to process is done by the makefile and passed via
> $* ?  Sounds reasonable.
>
> But calling genLang for all files in one directory introduces a number of
> sub processes, although not as much as before.  And much better than before.
>
>
>
>> Sorry that I forgot to mention that in my first mail.
>>
>> Jan.
>>
>>
>> On 6 November 2012 16:12, jan iversen<jancasacondor@gmail.**com<jancasacondor@gmail.com>>
>>  wrote:
>>
>>  HI
>>>
>>> Thanks for your input, it is not too harsh, I prefer straight comments
>>> than something I have to read several times to understand.
>>>
>>> I will not disturb your session, but I have put some reasons/answers
>>> below.
>>>
>>> rgds
>>> Jan I.
>>>
>>> On 6 November 2012 14:38, Andre Fischer<awf.aoo@gmail.com>  wrote:
>>>
>>>  On 11/4/12 1:55 PM, jan iversen wrote:
>>>>
>>>>  Hi.
>>>>>
>>>>> I have finished the control part of the new localization tool, and
>>>>> before I walk further down the line (writing/converting all the
>>>>> translations parts) I would like to have checked if the code is ok in
>>>>> terms
>>>>> of standard, readability and expectations (from other C++ programmers).
>>>>>
>>>>> I hope one of the C++ programmers, can have a quick look at the code
>>>>> and
>>>>> tell me:
>>>>> - Are the code written in accordance with the AOO standards (I think
>>>>> so)
>>>>> - Is it in general in accordance with the AOO writing style.
>>>>>
>>>>>  - C++ files usually have file extensions of .cxx and .hxx
>>>>
>>>> - There are some conventions of naming variables like mnSomthing for a
>>>> numerical member variable.
>>>>
>>>> I can live with you using a different naming scheme but would ask to
>>>> change the file extensions.
>>>>
>>>
>>> I will change the extensions, no problem...I use hungarian notation for
>>> variables, and I know that some system require e.g. int variable to start
>>> with a lower case "i", something I am not to much friend of, because it
>>> gets very cluttered when you make your own classes.
>>>
>>
> We don't use full hungarian notation, just an m for member variables and
> then and n for numbers, s for strings, r for references, p for pointers, a
> for everything else.  But I am a big friend of formatting your code as you
> feel comfortable with.  But try to keep it readable by others.  Eventually
> your code will have to be maintained by somebody else.
>
>
>
>>>
>>>
>>>>
>>>>  Of course, I would very much like to hear if there are non-efficient /
>>>>> malicious code in there, but please remember this is only the control
>>>>> skeleton, so there are a lot of code missing.
>>>>>
>>>>>  I only found one thing:
>>>>
>>>> genConvert.cpp  convert_gen::getConverter
>>>>
>>>> - There are two if statements at the start of the method.  The second
>>>> looks like it should be a "else if" instead.
>>>>
>>>>  UPS, corrected.
>>>
>>>  - The return at the bottom looks unreachable.
>>>>
>>>>  The return is actually just to please the compiler, it cannot be
>>> reached...but try to remove the statement and you get errors.
>>>
>>
> Ah, I see.
>
>
>
>>>
>>>
>>>>
>>>> But the main thing that I am not sure about is whether C++ is the right
>>>> language for this.  I am not sure because I have not found the
>>>> interesting
>>>> part of the program: how the file tree is traversed, how external tools
>>>> are
>>>> called, or whether there are not external tools anymore.
>>>>
>>>> If the main task of genLang is to traverse the file tree and call
>>>> external tools, then a script language like Perl might be better suited
>>>> and
>>>> would speed up implementation a lot.
>>>>
>>>
>>> No, there will be no external tools...all will be embedded in genLang, I
>>> am right now embedding transex3 (which is a lex grammar), each conversion
>>> is done as its own class, making it easy to expand.
>>>
>>> Localize_sl, spawns today different processes, written in C++, Lex, bash,
>>> python and bash....that is not maintainable, making it with classes as
>>> one
>>> program in C++ makes it easier to maintain.
>>>
>> I agree and I am glad that you are doing it this way.  I also agree that
> C++ is the right choice of language when all the external tools are
> integrated.
>
>
>
>>> I have done some speed test (based on some input I got on localize_sl).
>>> On
>>> windows localize_sl takes about 2 minutes to complete "sw" directory,
>>> mainly due to spawning a new process for each file. My preliminary test
>>> makes me believe that genLang will do the same in less than 10 seconds.
>>>
>>>
>>>
>>>>
>>>>  I try to include a zip file with this mail, should I not succeed, then
>>>>> please respond to the mail and I will sent it directly.
>>>>>
>>>>>  If the above sounds too harsh, then that is because I am currently
>>>> sitting in the BoF seesion and am trying to concentrate on two things at
>>>> the same time.
>>>>
>>>>  THANKS for taking time, have a nice session.
>>>
>>> I have on the other hand been searching for unit test tools, it seems we
>>> are not really using that....my biggest fear is to build something (of
>>> course with high reuse of source) without being able to guarantee that
>>> the
>>> output is identical to the old process.
>>>
>>
> Yes, using unit tests would be good.  Don't be as lazy as the rest of us
> :-)
>
>
>
>>>
>>>  -Andre
>>>>
>>>>
>>>>
>>>>  MANY Thanks in advance for the help.
>>>>> Jan.
>>>>>
>>>>>
>>>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message