Return-Path: 
 <dev-return-28810-apmail-openoffice-dev-archive=openoffice.apache.org@openoffice.apache.org>
X-Original-To: apmail-openoffice-dev-archive@www.apache.org
Delivered-To: apmail-openoffice-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id EBBC9D2FA
	for <apmail-openoffice-dev-archive@www.apache.org>;
 Tue,  6 Nov 2012 17:00:21 +0000 (UTC)
Received: (qmail 63383 invoked by uid 500); 6 Nov 2012 17:00:21 -0000
Delivered-To: apmail-openoffice-dev-archive@openoffice.apache.org
Received: (qmail 63106 invoked by uid 500); 6 Nov 2012 17:00:20 -0000
Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@openoffice.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@openoffice.apache.org>
List-Post: <mailto:dev@openoffice.apache.org>
List-Id: <dev.openoffice.apache.org>
Reply-To: dev@openoffice.apache.org
Delivered-To: mailing list dev@openoffice.apache.org
Received: (qmail 63082 invoked by uid 99); 6 Nov 2012 17:00:19 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Nov 2012 17:00:19 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of jancasacondor@gmail.com
 designates 209.85.219.46 as permitted sender)
Received: from [209.85.219.46] (HELO mail-oa0-f46.google.com) (209.85.219.46)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Nov 2012 17:00:11 +0000
Received: by mail-oa0-f46.google.com with SMTP id h16so706733oag.33
        for <dev@openoffice.apache.org>; Tue, 06 Nov 2012 08:59:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=GK4qsMXdTarfxLb+3+H8ozqh0DO0lLKgP4Jz5HVRUCI=;
        b=UIX3kxJN0o5EiOO378cl+GohI9gS5w4hx0fZJYTHluYBP3bCPWV+GCjcaYOQTnWYER
         404X5uyE7LeibfeUIjHo8zaI3hzBFvblZiPK3hwj0vd2lHQujELYglxyneNc8tHK/Hd6
         HWdJPxTu04a9MrdCtXQ8aaeOZxsVV1ifH7IBYeUqlPIjEFI5p3fWD4VwwiHhZ1Wpysk8
         jGQqxPBTRYT7JuYsTYmVzXuUvDD9orrEdMu16IVVOH25aoGqthChD5amFgrRlrBoAJaC
         AVPYnhflK2Y6w1PN/9W4EPFDdQIIiJMJXmodH1ERxS3zLLvy3vVlyuPoCRUoWtA0oBWR
         nJFA==
MIME-Version: 1.0
Received: by 10.60.13.132 with SMTP id h4mr1380593oec.72.1352221190512; Tue,
 06 Nov 2012 08:59:50 -0800 (PST)
Received: by 10.76.91.9 with HTTP; Tue, 6 Nov 2012 08:59:50 -0800 (PST)
In-Reply-To: 
 <CAK2iWdQXbN50jDSu-56nv7aEnyUEvXdJ18+6qNSG3eOsccdvSA@mail.gmail.com>
References: 
 <CAK2iWdRWQYCtbb3vDtwGh4Sk3KocB2ee9QizLiGdAw_qSoxizw@mail.gmail.com>
	<509912C6.3010906@googlemail.com>
	<CAK2iWdQXbN50jDSu-56nv7aEnyUEvXdJ18+6qNSG3eOsccdvSA@mail.gmail.com>
Date: Tue, 6 Nov 2012 17:59:50 +0100
Message-ID: 
 <CAK2iWdR00iGnOSb-SaGu+WGFRA-tboz0MatAJ46R-jKeGcENUQ@mail.gmail.com>
Subject: Re: [early codereview / check for standards] genLang in l10ntools
From: jan iversen <jancasacondor@gmail.com>
To: dev@openoffice.apache.org
Content-Type: multipart/alternative; boundary=e89a8fb20418b7dfd104cdd687bb
X-Virus-Checked: Checked by ClamAV on apache.org

--e89a8fb20418b7dfd104cdd687bb
Content-Type: text/plain; charset=ISO-8859-1

@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.

Sorry that I forgot to mention that in my first mail.

Jan.


On 6 November 2012 16:12, jan iversen <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.
>
>
>>
>>
>>
>>> 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.
>
>
>>
>>
>>
>> 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 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.
>
>
>>
>> -Andre
>>
>>
>>
>>> MANY Thanks in advance for the help.
>>> Jan.
>>>
>>>
>>
>

--e89a8fb20418b7dfd104cdd687bb--