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 08CECD8AA for ; Tue, 6 Nov 2012 18:56:38 +0000 (UTC) Received: (qmail 79370 invoked by uid 500); 6 Nov 2012 18:56:37 -0000 Delivered-To: apmail-openoffice-dev-archive@openoffice.apache.org Received: (qmail 79308 invoked by uid 500); 6 Nov 2012 18:56:37 -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 79299 invoked by uid 99); 6 Nov 2012 18:56:37 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Nov 2012 18:56:37 +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 (athena.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 18:56:31 +0000 Received: by mail-oa0-f46.google.com with SMTP id h16so871803oag.33 for ; Tue, 06 Nov 2012 10:56:10 -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=sCNgvu3/w6E9CrnEcI9/KHAYKe6IEQjX6i3VMTRPYfs=; b=MS7Hp6KCXiajPMC6aQ1petGkJlHgqtsEmK+fA6OnVp91WF+liOXdbVXnWPA1qdP9Sa k61y0TQ95Gctc405S+S9Nm1gM9wsvVVTiDWWqE4ATdJcFwcMkpOEMOq+XAi4m2KtZO1J lWO9Yqip8pqvFzfTR4SKCoEmRD7/GWuPIAOyvJ24ZtjZm9ViTkfHdcqbGh1A2hhMuR5S 5UOSv5W3FzfUdwmn19W5XoOMtL07feAppKZMzBJ8HFbhT6vxHK/QeBe5NgqNz00gMVB5 RLWa91ihb6RMFozevgStYsS+33VbTISYJZQjsqkeyAx2ZnagHGFb0s1izqf851mKFeMU pbeQ== MIME-Version: 1.0 Received: by 10.60.169.48 with SMTP id ab16mr1720190oec.15.1352228170362; Tue, 06 Nov 2012 10:56:10 -0800 (PST) Received: by 10.76.91.9 with HTTP; Tue, 6 Nov 2012 10:56:10 -0800 (PST) In-Reply-To: <509957EA.1020807@googlemail.com> References: <509912C6.3010906@googlemail.com>

<509957EA.1020807@googlemail.com> Date: Tue, 6 Nov 2012 19:56:10 +0100 Message-ID: Subject: Re: [early codereview / check for standards] genLang in l10ntools From: jan iversen To: dev@openoffice.apache.org Content-Type: multipart/alternative; boundary=bcaec54c4d62bff0be04cdd82787 X-Virus-Checked: Checked by ClamAV on apache.org --bcaec54c4d62bff0be04cdd82787 Content-Type: text/plain; charset=ISO-8859-1 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 -t 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 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 -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. >>>>> >>>>> >>>>> > --bcaec54c4d62bff0be04cdd82787--