Return-Path: 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 63964D7D0 for ; Tue, 6 Nov 2012 18:32:34 +0000 (UTC) Received: (qmail 6673 invoked by uid 500); 6 Nov 2012 18:32:34 -0000 Delivered-To: apmail-openoffice-dev-archive@openoffice.apache.org Received: (qmail 6600 invoked by uid 500); 6 Nov 2012 18:32:33 -0000 Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openoffice.apache.org Delivered-To: mailing list dev@openoffice.apache.org Received: (qmail 6592 invoked by uid 99); 6 Nov 2012 18:32:33 -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 18:32:33 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of awf.aoo@gmail.com designates 209.85.214.46 as permitted sender) Received: from [209.85.214.46] (HELO mail-bk0-f46.google.com) (209.85.214.46) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Nov 2012 18:32:24 +0000 Received: by mail-bk0-f46.google.com with SMTP id jk13so395429bkc.33 for ; Tue, 06 Nov 2012 10:32:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4OFVwDKKNFNfsCjKO6so9ylYvyLqxlrGVIWK1F4MVYU=; b=bAfIywy/TVRWZPgVIgX/9rv58N6xLsl/MAWs2A4BcR+4VFXtjopuAkOsw5I5gg9DXj eq+TMuYQ+8xiomrjZCwpIkjq6mGnBHGuVluJw1yXgtURKO5VLGl6arwF7MsgnAmO8EmE bnjQbl05G1uDso+y8TJp9DCkWFHwACECsXJFT4SIeN5v8d8PWPDcUxd0vZXDi6SrTQVQ XgTkRYDpvGpJXaB6dnhyszkdAzpAaxbXgxSXT94s27rr7vREudD5yMQYZvzrmUY+uJVK pPgIBGrMui/Vf1Rj0J3rcz+R8axnccyGb9ssxPTIKpHkadnS7n6q9UVMYTTSV+Q1aXtG +26Q== Received: by 10.204.149.208 with SMTP id u16mr494616bkv.93.1352226723677; Tue, 06 Nov 2012 10:32:03 -0800 (PST) Received: from [172.16.1.132] ([62.159.107.164]) by mx.google.com with ESMTPS id gy18sm12945104bkc.4.2012.11.06.10.32.02 (version=SSLv3 cipher=OTHER); Tue, 06 Nov 2012 10:32:02 -0800 (PST) Message-ID: <509957EA.1020807@googlemail.com> Date: Tue, 06 Nov 2012 19:33:14 +0100 From: Andre Fischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dev@openoffice.apache.org Subject: Re: [early codereview / check for standards] genLang in l10ntools References: <509912C6.3010906@googlemail.com>

In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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 -t $* > > 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 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 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. >>>> >>>>