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
Re: [dev] FASTBOOL macro vs bool - decrease memory usage
On 06/24/2010 12:42 PM, 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? Thinking again about suggestion I'm starting to see its merits. It's not because it's more safe (we should be able to do both changes in the right way), but it's surely faster. The primary motivation of us (the framework team) to start that work was that we wanted to get rid of a possible build breaker that has hit us every few months in the past. Types like BOOL, USHORT etc. are not only defined in tools/inc/tools/solar.h, but also in a Windows header. Moreover, the Windows API header defines them differently in many cases. So if you use the tools types, you must avoid to include the offending Windows headers. While that is annoying enough, it becomes a pain if you use precompiled headers. So it happens at times that a Windows build works without PCH but breaks with them. I had that several times in the past. A change from BOOL to sal_Bool indeed would be much faster than an attempt to use bool as much as possible, so it would be tempting to go that road and postpone a further replacement of sal_Bool by bool. We should ask the developers doing the work (some guys from RedOffice) what their own choice is. I don't know if they are reading this list, they surely read d...@framework, so I will ask there. 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
[dev] Re: FASTBOOL macro vs bool - decrease memory usage
On 25/06/2010 08:53, Stephan Bergmann wrote: 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.) well, the last time i found something like this it was just plain uninitialized memory. i guess somebody should investigate where the value came from. -- Jody: You realize your negative approach to everything is self-defeating, right? Daria: Well, it's nice to know there's _someone_ I can defeat. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Builld Error code 2
On 25/06/2010 06:45, Juan Manuel wrote:
Keep getting this error during build on Ubuntu 10.04. Tried changing the
permissions but error still remains. Any ideas?
it seems the makefile there deletes the stuff and re-generates it, so
it'll overwrite any manual change.
dpkg-deb
--build ../../unxlngx6.pro/misc/openoffice.org3.3-debian-menus_3.3-9511_all
/host/OpenOffice/sysui/unxlngx6.pro/bin/desktop-integration/openoffice.org3.3-debian-menus_3.3-9511_all.deb
dpkg-deb: building package `openoffice.org-debian-menus' in
`/host/OpenOffice/sysui/unxlngx6.pro/bin/desktop-integration/openoffice.org3.3-debian-menus_3.3-9511_all.deb'.
dpkg-deb: control directory has bad permissions 777 (must be =0755 and
=0775)
dmake: Error code 2, while making
'/host/OpenOffice/sysui/unxlngx6.pro/bin/desktop-integration/openoffice.org3.3-debian-menus_3.3-9511_all.deb'
apparently your dpkg has stricter error checking than older ones.
please try if the attached (untested) patch improves your build experience.
if it does i'll open an issue so it gets committed.
--
Save the environment. Create a closure today. -- Cormac Flanagan
diff -r 5bd839f4651b sysui/desktop/debian/makefile.mk
--- a/sysui/desktop/debian/makefile.mk Thu Jun 24 17:34:59 2010 +0200
+++ b/sysui/desktop/debian/makefile.mk Fri Jun 25 10:26:24 2010 +0200
@@ -85,7 +85,7 @@
-$(RM) $(@:d)$(@:f:s/_/ /:1)_*
$(RM) -r $(MISC)$/$(@:b)
dmake $(MISC)$/$(@:b)$/DEBIAN$/{control postinst postrm prerm}
- @chmod -R g-w $(MISC)$/$(@:b)
+ @chmod -R go-w $(MISC)$/$(@:b)
@chmod a+rx $(MISC)$/$(@:b)$/DEBIAN $(MISC)/$(@:b)/DEBIAN/post* $(MISC)/$(@:b)/DEBIAN/pre*
@chmod g-s $(MISC)/$(@:b)/DEBIAN
@mkdir -p $(PKGDIR)
-
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? Thinking again about suggestion I'm starting to see its merits. It's not because it's more safe (we should be able to do both changes in the right way), but it's surely faster. The primary motivation of us (the framework team) to start that work was that we wanted to get rid of a possible build breaker that has hit us every few months in the past. Types like BOOL, USHORT etc. are not only defined in tools/inc/tools/ solar.h, but also in a Windows header. Moreover, the Windows API header defines them differently in many cases. So if you use the tools types, you must avoid to include the offending Windows headers. This problem has been solved for many years now by using wrappers for external headers such as tools/prewin.h+tools/postwin.h tools/prex.h +tools/postx.h or tools/premac.h+tools/postmac.h. A change from BOOL to sal_Bool indeed would be much faster than an attempt to use bool as much as possible, so it would be tempting to go that road and postpone a further replacement of sal_Bool by bool. The wrappers mentioned above are a bit hacky and I'd be happy to get rid of them. With the conflicting definitions for the fundamental types gone this would be a step in that direction. So +1 from me getting rid of our BOOL. --- Herbert Duerr du...@sun.com - 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
Am 25.06.2010 09:20, schrieb Mathias Bauer: On 06/24/2010 12:42 PM, 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? Thinking again about suggestion I'm starting to see its merits. It's not because it's more safe (we should be able to do both changes in the right way), but it's surely faster. The primary motivation of us (the framework team) to start that work was that we wanted to get rid of a possible build breaker that has hit us every few months in the past. Types like BOOL, USHORT etc. are not only defined in tools/inc/tools/solar.h, but also in a Windows header. Moreover, the Windows API header defines them differently in many cases. So if you use the tools types, you must avoid to include the offending Windows headers. While that is annoying enough, it becomes a pain if you use precompiled headers. So it happens at times that a Windows build works without PCH but breaks with them. I had that several times in the past. A change from BOOL to sal_Bool indeed would be much faster than an attempt to use bool as much as possible, so it would be tempting to go that road and postpone a further replacement of sal_Bool by bool. We should ask the developers doing the work (some guys from RedOffice) what their own choice is. I don't know if they are reading this list, they surely read d...@framework, so I will ask there. Hi, Zhangxiaofei wants to exchange BOOL with sal_Bool on the first run. That exchange was also mentioned in a comment in the solar.h header file. I also think that this is a much easier way to get the work done and we can faster get rid of these old clashing types. Later we can do the transition from sal_Bool to bool. Regards, Carsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Buid OpenOffice 3.20 on Window
vuhung wrote:
2010/6/24 Lê Việt Quang levietquan...@gmail.com
I think you have reached this page:
http://qa.openoffice.org/issues/show_bug.cgi?id=110354historysort=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
vuhung16plus%7bremove...@gmail.dot.com, YIM: vuhung16 , Skype:
vuhung16plus
A brief profile: http://www.hn.is.uec.ac.jp/~vuhung/Nguyen.Vu.Hung.html
Thank you verry much , but I have trouble :-((
--
View this message in context:
http://old.nabble.com/Buid-OpenOffice-3.20-on-Window-tp28981313p28990682.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] FASTBOOL macro vs bool - decrease memory usage
On 06/25/2010 10:48 AM, Herbert Duerr 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? Thinking again about suggestion I'm starting to see its merits. It's not because it's more safe (we should be able to do both changes in the right way), but it's surely faster. The primary motivation of us (the framework team) to start that work was that we wanted to get rid of a possible build breaker that has hit us every few months in the past. Types like BOOL, USHORT etc. are not only defined in tools/inc/tools/solar.h, but also in a Windows header. Moreover, the Windows API header defines them differently in many cases. So if you use the tools types, you must avoid to include the offending Windows headers. This problem has been solved for many years now by using wrappers for external headers such as tools/prewin.h+tools/postwin.h tools/prex.h+tools/postx.h or tools/premac.h+tools/postmac.h. No, that doesn't work when PCH come into play, as experience shows. And it's an awful hack. Those who invented it (instead of *fixing* the problem when it was much easier than today as we had much less code!) should be punished by urging them to watch soccer games from France and Italy for at least three days without pausing. :-) Ciao, 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] Problems building DEV300_m83 on Windows.
This is weird. So all the other modules have been built correctly? cd into ./DEV300_m83/instsetoo_native and do build.pl verbose=true (so you will se commands invoked). I had a issue building in the instsetoo_native/util directory. But there was an error message. I solved it entering it, doing dmake util (instead of simply dmake) and then it was built correctly. Since the makefile.mk inside the contains TARGET=util at the top, I can't understand very -Mensaje original- De: Kristján Bjarni Guðmundsson [mailto:kristjanbja...@gmail.com] Enviado el: viernes, 25 de junio de 2010 15:44 Para: dev@openoffice.org Asunto: [dev] Problems building DEV300_m83 on Windows. Can anybody help me. I am trying to build DEV300_m83 on Windows with my language, and getting an error. My configure is following: ./configure --without-junit --disable-nss-module --disable-activex --with-lang=is --with-vendor=OpenOffice.is --with-build-version=Build by OpenOffice.is --disable-directx --disable-epm --disable-atl --disable-build-mozilla --with-cl-home=/cygdrive/C/Program Files/Microsoft Visual Studio 9.0/VC --with-ant-home=/cygdrive/c/winapps/java/ant --with-frame-home=/cygdrive/C/Program Files/Microsoft SDKs/Windows/v6.1 --with-psdk-home=/cygdrive/C/Program Files/Microsoft SDKs/Windows/v6.1 --with-midl-path=/cygdrive/C/Program Files/Microsoft SDKs/Windows/v6.1/Bin --with-asm-home=/cygdrive/C/Program Files/Microsoft Visual Studio 9.0/VC/Bin --with-jdk-home=/cygdrive/C/Winapps/java/jdk16 --with-csc-path=/cygdrive/C/WINDOWS/Microsoft.NET/Framework/v3.5 And the error is: Entering /cygdrive/c/Backup/OpenOffice/DEV300_m83/instsetoo_native/util 1 module(s): instsetoo_native need(s) to be rebuilt Reason(s): Attention: if you fix the errors in above module(s) you may prolongue your the build issuing command: build --all:instsetoo_native dmake: makefile.mk: line 216: Error: -- Missing targets or attributes in rule dmake: Error code 1, while making 'build_instsetoo_native' Aviso legal – Comisión Nacional del Mercado de Valores Este mensaje y, en su caso, los ficheros que lleve incorporados, está dirigido exclusivamente a su destinatario y es de carácter confidencial. Si fuere recibido por error o se tuviere conocimiento del mismo sin ser su destinatario, rogamos nos lo comunique por la misma vía o telefónicamente (91 585 15 00) y proceda a su destrucción, debiendo abstenerse de utilizar, transmitir, divulgar o reproducir la información contenida en el mismo. La CNMV se reserva las acciones legales que procedan contra todo tercero que acceda de forma ilegítima al contenido de cualquier mensaje externo procedente de la entidad Para información y consultas visite nuestra web: http://www.cnmv.es Disclaimer - Comisión Nacional del Mercado de Valores This message, its content and any file attached thereto is for the intended recipient only and is confidential. If you have received this e-mail in error or had access to it, you should note that the information in it is private and any use thereof is unauthorised. In such an event please notify us by e-mail or by telephone (+ 34 91 585 15 00). Any reproduction of this e-mail by whatsoever means and any transmission or dissemination thereof to other persons is prohibited. The Comisión Nacional del Mercado de Valores reserves the right to take legal action against any persons unlawfully gaining access to the content of any external message it has emitted For additional information, please visit our website: http://www.cnmv.es
Re: [dev] Buid OpenOffice 3.20 on Window
On Fri, Jun 25, 2010 at 5:04 PM, kanminru levietquan...@gmail.com wrote:
Thank you verry much , but I have trouble :-((
Let's share the errors you got.
cf.
http://www.openoffice.org/servlets/BrowseList?list=devby=threadfrom=2191749
With the help from the ML (dev@), I have been successfully built OOo, just
for fun
--
Best Regards,
Nguyen Hung Vu [aka: NVH] ( in Vietnamese: Nguyễn Vũ Hưng )
vuhung16plus{remo...@gmail.dot.com
vuhung16plus%7bremove...@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: Builld Error code 2
This is the message I get when applying the patch, and the build still fails at the same spot. (Stripping trailing CRs from patch.) patching file b/sysui/desktop/debian/makefile.mk Hunk #1 FAILED at 85. 1 out of 1 hunk FAILED -- saving rejects to file b/sysui/desktop/debian/makefile.mk.rej To: dev@openoffice.org From: michael.st...@sun.com Date: Fri, 25 Jun 2010 10:27:36 +0200 Subject: [dev] Re: Builld Error code 2 On 25/06/2010 06:45, Juan Manuel wrote: Keep getting this error during build on Ubuntu 10.04. Tried changing the permissions but error still remains. Any ideas? it seems the makefile there deletes the stuff and re-generates it, so it'll overwrite any manual change. dpkg-deb --build ../../unxlngx6.pro/misc/openoffice.org3.3-debian-menus_3.3-9511_all /host/OpenOffice/sysui/unxlngx6.pro/bin/desktop-integration/openoffice.org3.3-debian-menus_3.3-9511_all.deb dpkg-deb: building package `openoffice.org-debian-menus' in `/host/OpenOffice/sysui/unxlngx6.pro/bin/desktop-integration/openoffice.org3.3-debian-menus_3.3-9511_all.deb'. dpkg-deb: control directory has bad permissions 777 (must be =0755 and =0775) dmake: Error code 2, while making '/host/OpenOffice/sysui/unxlngx6.pro/bin/desktop-integration/openoffice.org3.3-debian-menus_3.3-9511_all.deb' apparently your dpkg has stricter error checking than older ones. please try if the attached (untested) patch improves your build experience. if it does i'll open an issue so it gets committed. -- Save the environment. Create a closure today. -- Cormac Flanagan _ Express yourself with gadgets on Windows Live Spaces http://discoverspaces.live.com?source=hmtag1loc=us
