Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
On 06/24/10 22:51, Terrence Enger wrote: This is about a sal_Bool rather than a bool, but I shall raise the question anyway. It just happens that I was running OO under gdb, and the following output had already caught my attention. Breakpoint 1, connectivity::OSkipDeletedSet::moveAbsolute (this=0xa85faa14, _nPos=1, _bRetrieveData=244 'ô') at /home/terry/OOo_hacking/DEV300_m83/connectivity/source/commontools/TSkipDeletedSet.cxx:170 170 sal_Bool OSkipDeletedSet::moveAbsolute(sal_Int32 _nPos,sal_Bool _bRetrieveData Is the funny value of _bRetrieveData sufficient grounds to create an issue? Technically, it should be OK; a sal_Bool value == 0 represents false, while anything != 0 represents true. However, using anything but 0/1 is error-prone and probably dubious, so looking into it would definitely be worthwhile. (There is a slim chance that this is caused by compiler optimizations and is thus harmless, or that gdb displays garbage instead of the true function arguments, but the values for this and _nPos look reasonable enough to let you assume that the value for _bRetrieveData is correct also.) -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Community Council Elections 2010-06: Phase "Voting by the Constituency" Starts
Hi all, the phase "Voting by the Constituency" for the current OpenOffice.org Community Council elections starts now. The election process [1] instructs us to allot two weeks for voting. That period begins now and will end by July 8th 2010. The voting for the seat will be done by the corresponding constituency (see below). We have compiled a list of those who are eligible to vote and we will invite the members of the constituency by direct mail which explains how and where to vote. The wiki page [2] provides further information on the current elections. Nevertheless, we are going to vote for ... Product Development Representative Number of seats: One Constituency: Category leads, project leads and co-leads of all OpenOffice.org projects (accepted and incubator) but not from the native-lang category or l10n project. Candidates: Andreas Bartel, Thorsten Behrens http://wiki.services.openoffice.org/wiki/Community_Council/Elections/2010-06#Product_Development_Representative If you run into any problems feel free to contact the commissary and observers listed at [2]. Thank you and enjoy your day! Christoph (on behalf of the OpenOffice.org Community Council) REFERENCES [1] Election Process Bylaw http://wiki.services.openoffice.org/w/index.php?title=Community_Council/Items/Election_Process&oldid=165604 [2] Election 2010-06 http://wiki.services.openoffice.org/wiki/Community_Council/Elections/2010-06 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
On Thu, 2010-06-24 at 11:32 +0200, Stephan Bergmann wrote: > On 06/24/10 11:17, Bartosz wrote: > > Maybe we should change it to (or remove this macro): > > typedef bool FASTBOOL; > > Yes, best would certainly be to remove the typedef and change > occurrences of FASTBOOL to plain bool (watching out for potential > misuses that tunnel values other than true/false through a variable of > type FASTBOOL). This is about a sal_Bool rather than a bool, but I shall raise the question anyway. It just happens that I was running OO under gdb, and the following output had already caught my attention. Breakpoint 1, connectivity::OSkipDeletedSet::moveAbsolute (this=0xa85faa14, _nPos=1, _bRetrieveData=244 'ô') at /home/terry/OOo_hacking/DEV300_m83/connectivity/source/commontools/TSkipDeletedSet.cxx:170 170 sal_Bool OSkipDeletedSet::moveAbsolute(sal_Int32 _nPos,sal_Bool _bRetrieveData Is the funny value of _bRetrieveData sufficient grounds to create an issue? Cheers, Terry. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
Hi, On Thursday, 2010-06-24 14:44:35 +0200, Mathias Bauer wrote: > In result I expect that most "BOOL" can be replaced by "bool", while > some of them will become "sal_Bool". The misused "BOOLS" that in fact > are 8 Bit integer variables(*) IMHO should become a sal_uInt8/16 just to > show that they are *not* boolean. > > Anyway the change from BOOL to whatever is nothing that can be done just > with a script. That's different for e.g. USHORT. Just a quick idea: define BOOL (or FASTBOOL) as some class that has private ctors, conversion, assignment, bit and comparison operators for all integer types, but allow conversion to integers, define private SvStream operators, and public operators for comparison/conversion/assignment/construction with/to/from bool. Then compile the entire office ignoring return codes, i.e. let dmake not break, and wade through thousands of error messages.. A decent editor capable to digest compiler errors and position on the error is most helpful. I did similar back when we replaced (Byte)String with UniString, and when I changed Calc row variables from 16bit to 32bit, and it worked well. With a global BOOL replacement it would be quite some effort though. I think I still have that class layout and definitions for general use somewhere, so if anyone is interested and feels an itch.. ;-) Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the e...@sun.com account, which I use for mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks. pgpe7B4o0sZ3T.pgp Description: PGP signature
Re: [dev] Buid OpenOffice 3.20 on Window
2010/6/24 Lê Việt Quang
> I think this error may be caused by "Preprocessor startline:
> E:/ooo320_m19/solver/320/wntmsci12.pro/bin/rscpp @C:\Documents and
> Settings\Le Viet Quang\2F17.tmp", the file path should be mixed short path.
> However I do not know how to change the file path to mixed short path?
>
> I need some help , thank you very much .
>
I think you have reached this page:
http://qa.openoffice.org/issues/show_bug.cgi?id=110354&historysort=new
To change the environment variables in a .bat file, use the "set" command
like:
set tmp=f:\tmp
echo %tmp%
And be noted that environment variables in cygwin inherit from Windows'
Under cygwin, most likely you are using bash therefore the "export" command
will alter tham
export TMP=/cygwin/full/path (case sensitive)
Good luck.
--
Best Regards,
Nguyen Hung Vu [aka: NVH] ( in Vietnamese: Nguyễn Vũ Hưng )
vuhung16plus{remo...@gmail.dot.com
, YIM: vuhung16 , Skype:
vuhung16plus
A brief profile: http://www.hn.is.uec.ac.jp/~vuhung/Nguyen.Vu.Hung.html
Re: [dev] Re: "FASTBOOL macro" vs "bool" - decrease memory usage
Hi
Here is an excerpt from the C++ standard about the size of fundamental types
(clause 5.3.3) :
sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1; the result
of sizeof applied to any other fundamental type (3.9.1) is
implementation-defined. [Note: in particular, sizeof(bool) and
sizeof(wchar_t) are implementation-defined.69) ]
Regards
Patrick
Le jeudi 24 juin 2010, Stephan Bergmann a écrit :
> On 06/24/10 14:24, Rene Engelhard wrote:
> > On Thu, Jun 24, 2010 at 02:15:29PM +0200, Michael Stahl wrote:
> >> isn't bool ususally (or at least sometimes) 4 bytes in size?
> >
> > $ cat test.cxx
> > #include
> >
> > int main() {
> > printf("%d\n", sizeof(bool));
> > }
> > $ g++ -o lala ./test.cxx
> > $ ./lala
> > 1
>
> sizeof(bool) is implementation-defined, but typically 1.
>
> -Stephan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
> For additional commands, e-mail: dev-h...@openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
On 24.06.2010 12:42, Niklas Nebel wrote: On 06/24/10 12:29, Mathias Bauer wrote: The idea is so good that someone is already working on it. :-) There is ongoing work to replace a lot of ancient types like BOOL, USHORT etc. by sal_... types, with the exception that BOOL/FASTBOOl will be replaced by bool. "BOOL -> bool" will cause problems. Memory usage for "new BOOL[n]", mixed use with sal_Bool (pointers, references), the occasional "special" value (SfxChildWinInfo::bVisible). Shouldn't we go the safe way and change BOOL to sal_Bool instead? In result I expect that most "BOOL" can be replaced by "bool", while some of them will become "sal_Bool". The misused "BOOLS" that in fact are 8 Bit integer variables(*) IMHO should become a sal_uInt8/16 just to show that they are *not* boolean. Anyway the change from BOOL to whatever is nothing that can be done just with a script. That's different for e.g. USHORT. Regards, Mathias (*) The famous cases where a "BOOL" parameter was used as an 8 Bit integer to keep (formal) compatibility. -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: "FASTBOOL macro" vs "bool" - decrease memory usage
On 06/24/10 14:24, Rene Engelhard wrote:
On Thu, Jun 24, 2010 at 02:15:29PM +0200, Michael Stahl wrote:
isn't bool ususally (or at least sometimes) 4 bytes in size?
$ cat test.cxx
#include
int main() {
printf("%d\n", sizeof(bool));
}
$ g++ -o lala ./test.cxx
$ ./lala
1
sizeof(bool) is implementation-defined, but typically 1.
-Stephan
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: "FASTBOOL macro" vs "bool" - decrease memory usage
Hi,
On Thu, Jun 24, 2010 at 02:15:29PM +0200, Michael Stahl wrote:
> isn't bool ususally (or at least sometimes) 4 bytes in size?
$ cat test.cxx
#include
int main() {
printf("%d\n", sizeof(bool));
}
$ g++ -o lala ./test.cxx
$ ./lala
1
Grüße/Regards,
René
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
On 06/24/10 13:52, Stephan Bergmann wrote: Re memory usage: BOOL[n] and bool[n] would each be n bytes in size, or what am I missing? You're right, forget about that part. Re mixed use with sal_Bool: haven't encountered this problem often over the last years (and I liberally use bool instead of sal_Bool/BOOL since ages) -- also, it might be better to try to adapt the mismatching uses of sal_Bool to bool, too, leaving usage of sal_Bool to the only place it belongs, C++ UNO. If you write new code, you see what you're doing. In existing code, BOOL and sal_Bool are often used interchangeably. sal_Bool only belonging to UNO may be a good idea, but not reality. And I don't see an easy way to adapt existing code to that rule. If we change the typedef and then go through the list of compiler errors, we'll only end up with something like "sal_Bool bSalFoo(bFoo); process(bSalFoo); bFoo=bSalFoo;" and probably still break something that's found only years later. Re the occasional "special" value: I guess one day we should bite the bullet and clean those up for good. That might be a good thing anyway. But then it should be done separately, so the result can be compiled and tested immediately. Niklas - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: "FASTBOOL macro" vs "bool" - decrease memory usage
On 24/06/2010 13:52, Stephan Bergmann wrote: > On 06/24/10 12:42, Niklas Nebel wrote: >> On 06/24/10 12:29, Mathias Bauer wrote: >>> The idea is so good that someone is already working on it. :-) >>> There is ongoing work to replace a lot of ancient types like BOOL, >>> USHORT etc. by sal_... types, with the exception that BOOL/FASTBOOl >>> will be replaced by bool. >> "BOOL -> bool" will cause problems. Memory usage for "new BOOL[n]", >> mixed use with sal_Bool (pointers, references), the occasional "special" >> value (SfxChildWinInfo::bVisible). Shouldn't we go the safe way and >> change BOOL to sal_Bool instead? > > Re memory usage: BOOL[n] and bool[n] would each be n bytes in size, or > what am I missing? isn't bool ususally (or at least sometimes) 4 bytes in size? but actually instead of BOOL[n] some kind of bit vector could be used, which would take even less space, right? > Re mixed use with sal_Bool: haven't encountered this problem often over > the last years (and I liberally use bool instead of sal_Bool/BOOL since > ages) -- also, it might be better to try to adapt the mismatching uses > of sal_Bool to bool, too, leaving usage of sal_Bool to the only place it > belongs, C++ UNO. actually, i've just recently cleaned up a part of the UNO API implementation in the writer; a few of the method implementations used BOOL in the signature instead of sal_Bool (usually the header used one and the implementation the other...) this happens to work because C++ doesn't take type safety seriously, and they're both unsigned char. that's something to watch out for: here BOOL must be replaced with sal_Bool. > Re the occasional "special" value: I guess one day we should bite the > bullet and clean those up for good. seconded. > -Stephan -- Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
On 06/24/10 12:42, Niklas Nebel wrote: On 06/24/10 12:29, Mathias Bauer wrote: The idea is so good that someone is already working on it. :-) There is ongoing work to replace a lot of ancient types like BOOL, USHORT etc. by sal_... types, with the exception that BOOL/FASTBOOl will be replaced by bool. "BOOL -> bool" will cause problems. Memory usage for "new BOOL[n]", mixed use with sal_Bool (pointers, references), the occasional "special" value (SfxChildWinInfo::bVisible). Shouldn't we go the safe way and change BOOL to sal_Bool instead? Re memory usage: BOOL[n] and bool[n] would each be n bytes in size, or what am I missing? Re mixed use with sal_Bool: haven't encountered this problem often over the last years (and I liberally use bool instead of sal_Bool/BOOL since ages) -- also, it might be better to try to adapt the mismatching uses of sal_Bool to bool, too, leaving usage of sal_Bool to the only place it belongs, C++ UNO. Re the occasional "special" value: I guess one day we should bite the bullet and clean those up for good. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
On 06/24/10 13:07, Bartosz wrote: "BOOL -> bool" will cause problems. Memory usage for "new BOOL[n]", mixed use with sal_Bool (pointers, references), the occasional "special" value (SfxChildWinInfo::bVisible). Shouldn't we go the safe way and change BOOL to sal_Bool instead? I agree with you Niklas. It will be much better/safer to change FASTBOOL to sal_Bool. I was talking about BOOL, not FASTBOOL. FASTBOOL usage is much more limited. Replacing FASTBOOL with bool seems possible and more in line with its original intention. I agree with Stephan that it's best to remove the FASTBOOL type altogether and change the places where it's used (much fewer than for BOOL). Niklas - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
> > "BOOL -> bool" will cause problems. Memory usage for "new BOOL[n]", mixed > use with sal_Bool (pointers, references), the occasional "special" value > (SfxChildWinInfo::bVisible). Shouldn't we go the safe way and change BOOL to > sal_Bool instead? I agree with you Niklas. It will be much better/safer to change FASTBOOL to sal_Bool. Does sal_Bool(unsigned char) is slower than FASTBOOL (int)? It could make OpenOffice.org code slower if it will call functions with bool parameters a lot. I don't want to loose the performance, see: http://cboard.cprogramming.com/cplusplus-programming/119320-bool-vs-int-faster.html Regards Bartosz - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Buid OpenOffice 3.20 on Window
Hi all !
I am very sorry for the inconvenience , I try to build ooo320_m19 on WinXP ,
I try to do as
http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Windowsbut
It fail and take this Error :
build -- version: -
> =
> Building module sccomp
> /cygdrive/e/ooo320_m19/sccomp/source/solver
> --
> Making: ../../wntmsci12.pro/srs/solver.srs
> : && PATH=${PATH}:/cygdrive/E/ooo320_m19/solver/320/wntmsci12.pro/bin
> slfl.pl E:/ooo320_m19/solver/320/wntmsci12.pro/bin/rsc -presponse
> @E:/Cygwin/tmp/mk8O06iA
> cpp: line 0, Error: Too many file arguments. Usage: cpp [input [output]]
> VCL Resource Compiler 3.0
> Preprocessor commandline: -I. -I. -I..\..\wntmsci12.pro\inc\solver
> -I..\inc -I..\..\inc\pch -I..\..\inc -I..\..\WIN\inc -I..\..\wntmsci12.pro\inc
> -I. -IE:\ooo320_m19\solver\320\wntmsci12.pro\inc\stl
> -IE:\ooo320_m19\solver\320\wntmsci12.pro\inc\external
> -IE:\ooo320_m19\solver\320\wntmsci12.pro\inc
> -IE:\ooo320_m19\solenv\wntmsci12\inc -IE:\ooo320_m19\solenv\inc
> -IE:\ooo320_m19\res -IE:\ooo320_m19\solver\320\wntmsci12.pro\inc\stl
> -IC:\PROGRA~1\Java\JDK16~1.0_2\include\win32
> -IC:\PROGRA~1\Java\JDK16~1.0_2\include
> -IC:\PROGRA~1\MI2578~1\Windows\v6.1\include
> -IC:\PROGRA~1\MICROS~1.0\VC\include -IE:\ooo320_m19\solver\320\
> wntmsci12.pro\inc\offuh -I. -I..\..\res -I. -DWNT -DNT351 -DMSC -DM1500
> -DSOLAR_JAVA -DFULL_DESK -DPRODUCT -DPRODUCT_FULL -DNDEBUG
> -DOSL_DEBUG_LEVEL=0 -DUPDVER="320m19(Build:9505)" solver.src C:\Documents
> and Settings\Le Viet Quang\2F16.tmp
> Preprocessor startline:
> E:/ooo320_m19/solver/320/wntmsci12.pro/bin/rs...@c:\Documents and Settings\Le
> Viet Quang\2F17.tmp
> Error starting preprocessor
> dmake: Error code 1, while making '../../wntmsci12.pro/srs/solver.srs'
>
> ERROR: Error 65280 occurred while making
> /cygdrive/e/ooo320_m19/sccomp/source/solver
> rmdir E:/Cygwin/tmp/I4mOW_PSy1
>
I think this error may be caused by "Preprocessor startline:
E:/ooo320_m19/solver/320/wntmsci12.pro/bin/rscpp @C:\Documents and
Settings\Le Viet Quang\2F17.tmp", the file path should be mixed short path.
However I do not know how to change the file path to mixed short path?
I need some help , thank you very much .
--
Le Viet Quang
Faculty of Computer Science and Engineering
Hochiminh City University of Technology
Yahoo : kanminru
Email : levietquan...@gmail.com
Mobile : (+84) 1664 166 736
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
On 06/24/10 12:29, Mathias Bauer wrote: The idea is so good that someone is already working on it. :-) There is ongoing work to replace a lot of ancient types like BOOL, USHORT etc. by sal_... types, with the exception that BOOL/FASTBOOl will be replaced by bool. "BOOL -> bool" will cause problems. Memory usage for "new BOOL[n]", mixed use with sal_Bool (pointers, references), the occasional "special" value (SfxChildWinInfo::bVisible). Shouldn't we go the safe way and change BOOL to sal_Bool instead? Niklas - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
Hi, On 24.06.2010 11:17, Bartosz wrote: Hi. What do you think about replace macro "FASTBOOL" with "bool"? http://svn.services.openoffice.org/opengrok/xref/DEV300_m83/tools/inc/tools/solar.h#FASTBOOL For now the FASTBOOL is defined as: typedef int FASTBOOL; Maybe we should change it to (or remove this macro): typedef bool FASTBOOL; It was done, because "int" was faster than "bool". More info: http://cboard.cprogramming.com/cplusplus-programming/119320-bool-vs-int-faster.html Modern compilers are very smart, and I think we should leave optimization to them. What do you think about this idea? The idea is so good that someone is already working on it. :-) There is ongoing work to replace a lot of ancient types like BOOL, USHORT etc. by sal_... types, with the exception that BOOL/FASTBOOl will be replaced by bool. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
+1 for removing this ancient thing. Not for memory reasons (I doubt it would really make a difference), but for code cleanup reasons. I don't know how risky this is when it comes to the binfilter module. If the old binary filters simply stream FASTBOOL variables, the document format would become incompatible. But IIRC we seldom used stream operators in our filters, but used SvStream::Read/Write(...), which would be fine then. So you should first check if this is the case... Malte. Stephan Bergmann wrote, On 06/24/10 11:32: > On 06/24/10 11:17, Bartosz wrote: >> Maybe we should change it to (or remove this macro): >> typedef bool FASTBOOL; > > Yes, best would certainly be to remove the typedef and change > occurrences of FASTBOOL to plain bool (watching out for potential > misuses that tunnel values other than true/false through a variable of > type FASTBOOL). > > -Stephan > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.org > For additional commands, e-mail: dev-h...@openoffice.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] "FASTBOOL macro" vs "bool" - decrease memory usage
On 06/24/10 11:17, Bartosz wrote: Maybe we should change it to (or remove this macro): typedef bool FASTBOOL; Yes, best would certainly be to remove the typedef and change occurrences of FASTBOOL to plain bool (watching out for potential misuses that tunnel values other than true/false through a variable of type FASTBOOL). -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] "FASTBOOL macro" vs "bool" - decrease memory usage
Hi. What do you think about replace macro "FASTBOOL" with "bool"? http://svn.services.openoffice.org/opengrok/xref/DEV300_m83/tools/inc/tools/solar.h#FASTBOOL For now the FASTBOOL is defined as: typedef int FASTBOOL; Maybe we should change it to (or remove this macro): typedef bool FASTBOOL; It was done, because "int" was faster than "bool". More info: http://cboard.cprogramming.com/cplusplus-programming/119320-bool-vs-int-faster.html Modern compilers are very smart, and I think we should leave optimization to them. What do you think about this idea? Best Regards Bartosz - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build OpenOffice 3.20 on WinXP
Mathias Bauer wrote: > > > That's a strange error. What lets me wonder is that you seem to have two > different locations for temp files: c:\temp\... and e:/cygwin/tmp. Maybe > your TMP and TEMP locations are different? > > Regards, > Mathias > > -- > Mathias Bauer (mba) - Project Lead OpenOffice.org Writer > OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS > Please don't reply to "nospamfor...@gmx.de". > I use it for the OOo lists and only rarely read other mails sent to it. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.org > For additional commands, e-mail: dev-h...@openoffice.org > > Thank you verry much , I creat folder c:/temp and it can run now . -- View this message in context: http://old.nabble.com/Build-OpenOffice-3.20-on-WinXP-tp28968350p28980164.html Sent from the openoffice - dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build error in helpcontent2 (Lucene)
> Microsoft Patch
More like Windows Installer ("MSI") Patch, but yeah, means the same thing
basically anyway.
> As no one else is building them it's basically a Sun-only problem
We (Novell) have been trying to use MSI patching, with occasional success even,
for longer than Sun. But it has always been a nightmare.
--tml
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build error in helpcontent2 (Lucene)
Hi, On Wed, Jun 23, 2010 at 10:54:53PM +0200, Pavel Laštovička wrote: > citing from issue #103354: > > "During the massive parallel build of helpcontent2 the lucene indexer > generates index files which are renamed. This behavior breaks the MSP > pack process, were no files have to be removed." > > So renamed index files (cfs) are really a problem only on Sun builds? And Yes. > what is the MSP pack process? :-) Microsoft Patch (has to google myself when I read that in the issue). As no one else is building them it's basically a Sun-only problem (but that's why my initial patch made those checks on for Windows, but you can do that yourself if you wished by setting the new variable anyways). Grüße/Regards, René - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
