Re: [dev] ARM port
On Tue, 2011-02-15 at 10:15 +0100, eric b wrote: Anybody working on ARM port ? OpenOffice.org is already ported to Linux ARM, oabi and eabi, le and be. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] how to detect MS Office encrypted documents
On Mon, 2010-11-29 at 10:49 +0200, Filip wrote: Hello, I have to implement some tool that has the ability to detect whether a document created by Microsoft office 97-2010 (Word, For word, the binary format anyway, see sw/source/filter/ww8 and search for fEncrypted For the MS xml formats, see http://www.openoffice.org/issues/show_bug.cgi?id=92645 for some details of how they're stored. I'm vague on the details of the excel and ppt binary formats as to how to detect that they're encrypted. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] UniString removal
On Sat, 2010-09-18 at 19:31 +0200, Bartosz wrote: Hi, At TODO list there is topic about String and UniString removal: http://wiki.services.openoffice.org/wiki/To-Dos#General_Refactoring_Improvements I found some declaration of the String, ByteString, UniString at: http://svn.services.openoffice.org/opengrok/xref/DEV300_m87/tools/inc/tools/string.hxx Also OString declaration at file: http://svn.services.openoffice.org/opengrok/xref/DEV300_m87/sal/inc/rtl/string.hxx and OUString at: http://svn.services.openoffice.org/opengrok/xref/DEV300_m87/sal/inc/rtl/ustring.hxx What is the main differents between them and which one is obsolete? There are basically four string classes rtl::OString the favoured class where each unit is 8bit rtl::OUString the favoured class where each unit is 16bit ByteString, deprecated 8bit strings UniString (alias String) deprecated 16bit strings Generally should replace ByteString with rtl::OString and UniString with rtl::OUString. But also see rtl::OUStringBuffer and rtl::OStringBuffer when replacing UniString/ByteString as they're often necessary. C. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Import of relative links from .doc files.
On Tue, 2010-09-14 at 12:54 +0200, Knut Olav Bøhmer wrote: Hi, Attatched to this email is a document with a hyperlink that opens differently in MS Office and OpenOffi In word if you open the .doc and toggle field codes on you can see that the relative url is recorded as ..\\..\\FELLES.PROSESSER.doc#k11 in the field code itself which is the URL that OOo is taking and converting to an absolute URL relative to the location that the imported .doc is loaded from. (Not sure why we are turning it from relative to absolute in the .doc importer, sounds like a bad idea, but that's neither here not there in this case) But it looks like word *isn't* taking the field code itself as the url to display/use in this case, but instead using the value tucked away in the DocumentSummaryStream in the VtHyperlink sequence (I think), so it sort of looks like the algorithm for hyperlinks need to be to import the DocumentSummaryStream links and match them up with the fields they are associated with and use those links in favour of the inlines ones where they exist. A big of a nightmare, not sure how its possible to get them out of sync with each other. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Import of relative links from .doc files.
On Tue, 2010-09-14 at 14:40 +0200, Knut Olav Bøhmer wrote: Thank you for the analysis :) this really helps. What parts of the word document is available at the time of importing the hyperlink. Is all of the parts read in, so that the DocumentSummaryStream could be accessed at that time? It's not read in by the .doc importer currently. Some generic parts are read in by sfx2 to set generic properties, but there's something in sd/source/filter/ppt/pptin.cxx (search for _PID_HLINKS) which looks like roughtly the same kind of thing for the ppt format. That would also need to be done in the ww8 importer to parse them out and attempt the (weird and wonderful) mapping from dwApp to field code mentioned in the Application Data for VtHyperlink section of the .doc spec. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Import of relative links from .doc files.
On Tue, 2010-09-14 at 15:03 +0200, Knut Olav Bøhmer wrote: Are sfx2 reading it's parts before the .doc importer is read, and could OOo be set to read the relevant parts when sfx2 does it's work, and then save it for later? sfx2 reads different, more standardized parts. Directly pulling out these odd things in say SwWW8ImplReader::ReadDocInfo where pStg is a pointer to the same type of object as mrStorage is a reference to at http://svn.services.openoffice.org/opengrok/xref/Current%20%28trunk% 29/sd/source/filter/ppt/pptin.cxx#275 is probably a better way to go, stuff the info into some table belonging to SwWW8ImplReader and then in Read_F_Hyperlink try to lookup the matching entry in that table for the specific field index to get a replacement hyperlink if an entry exists. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Import of relative links from .doc files.
On Tue, 2010-09-14 at 16:58 +0200, Michael Stahl wrote: maybe it would make sense to move the property hyperlink blob decoding to sfx2 as well (if the format for xls/ppt/doc is the same, about which i have no idea). Yeah, poking at it, they parsing/decoding should unified in there seeing as at it currently stands the DocumentSummaryInformation stream is getting parsed twice for .ppt files. Given the current information about the hyperlink foo and .docs though, it would be important *not* to directly round trip the hyperlink blob in an import / export cycle seeing as modified hyperlinks in a .doc would apparently be ignored in favour of round-tripped DSI entries. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Import of relative links from .doc files.
On Mon, 2010-09-13 at 21:35 +0200, Knut Olav Bøhmer wrote: Is it possible to look at the strings in the word doc some how with hex/asci reader? If you have libgsf (e.g. on Linux) you can look at the WordDocument stream (which has the text in it and the fields are in the text with e.g. gsf dump test.doc WordDocument|less main document text typically starts around 0x400 or later in relatively recent word formats. On windows, there's some graphical ole2 viewer thing whose name I can't remember that you could use as well, a search for ole compound format viewer might throw it up. Disable fastsave in word if you are trying to cut a small document down to a small test-case as fastsave complicates matters somewhat. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Import of relative links from .doc files.
And as an aside, the hyperlink importer for the .doc format is in sw/source/filter/ww8 as SwWW8ImplReader::Read_F_Hyperlink and its a fairly trivial thing C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build broken on Fedora 13
On Thu, 2010-09-09 at 17:28 -0300, Santiago Bosio wrote: But, if you see the dates involved, the prebuilt binaries were uploaded on 2009/11/17, and the fix for the issue was provided on 2009/11/20, so I'm suspecting that these binaries don't have this correction. Yeah, its as simple as that alright. The binaries don't have the fix in them. Are there more recent prebuilt binaries, that include this fix, or should I compile the moz module from source using --enable-build-mozilla? I don't think there are any refreshed builds of those binaries, so easiest fix is to just build moz from source. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] possible to add a GraphicFilter extension ?
Is it possible to write an extension which adds another *graphic* filter to OOo, i.e. one which adds support for an additional format to insert-picture or theme-find files..., a cursory looks suggests that its not really possible. It looks like those ones are restricted to GraphicFilters which a) arbitrarily have to have one, and only one, flag of either import or export because of FilterConfigCache::ImplInit in svtools/source/filter.vcl/filter/FilterConfigCache.cxx b) is arbitrarily restricted to importing formats that have three letter suffixes c) Must be a .so in the brand/base dir due to #if defined WNT rtl::OUString url(RTL_CONSTASCII_USTRINGPARAM($BRAND_BASE_DIR/program)); #else rtl::OUString url(RTL_CONSTASCII_USTRINGPARAM($OOO_BASE_DIR/program)); #endif in svtools/source/filter.vcl/filter/filter.cxx and so on. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Cross compiling openoffice
On Tue, 2010-08-10 at 23:58 -0700, Soohong Min wrote: Dear Caolán McNamara, I've solved below problem, graphite but I had another problem about Hunspell I'm building module Hunspell, I got the following error message. make[2]: Leaving directory `/ooo-build-3.2.1.4/build/ooo320-m19/hunspell/unxlngr.pro/misc/build/hunspell-1.2.8' make[1]: *** [all] Error 2 make[1]: Leaving directory `/ooo-build-3.2.1.4/build/ooo320-m19/hunspell/unxlngr.pro/misc/build/hunspell-1.2.8' dmake: Error code 2, while making './unxlngr.pro/misc/build/so_built_hunspell' ERROR: Error 65280 occurred while making /ooo-build-3.2.1.4/build/ooo320-m19/hunspell/ rmdir /tmp/tSoQDREb15 make: *** [stamp/build] Error 1 If I don't install Hunspell, how can I do it? You've only listed the text that says there was an error, not the text of the error itself. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Cross compiling openoffice
On Tue, 2010-08-10 at 07:09 -0700, Soohong Min wrote: Hello, I am cross compiling OpenOffice for ARM. I got this error message checking whether db is at least 4.1... ./configure: line 13997: test: : integer expression expected configure: error: no. you need at least db 4.1 make: *** [stamp/build] Error 1 By the way, I've already installed db - 5.0.21-r0.5 I don't know how to solve this problem. Please let me know if possible. You haven't mentioned what version of OOo you are building. Probably you can fix this with either... a) build without the system db and use the internal one, e.g. --without-system-db b) maybe patch configure.in to accept a later db, e.g. see http://qa.openoffice.org/issues/show_bug.cgi?id=107058, and run autoconf afterwards to regenerate configure and try again c) or install db 4.X.Y Though I wonder if it might be a better idea to start by crosscompiling something easier, and work your way up to crosscompiling OOo C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Cross compiling openoffice
On Tue, 2010-08-10 at 07:39 -0700, Soohong Min wrote: Thank you for your reply. The version of OOo is 3.2.1.4. After patch, I can solve this problem but I still have another problem. checking which odbc headers to use... external checking sqlext.h usability... no checking sqlext.h presence... no checking for sqlext.h... no configure: error: odbc not found. install odbc install odbc or don't build using --with-system-* C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Cross compiling openoffice
On Tue, 2010-08-10 at 08:39 -0700, Soohong Min wrote: checking which sane header to use... external - checking sane/sane.h usability... no checking sane/sane.h presence... no checking for sane/sane.h... no configure: error: sane not found. install sane I need to install sane package but I am cross compiling Openoffice on bash (Angstrom linux) so I could not found this package. I also used './configure --with-system-sane =no or --with-system-sane-headers=no to build. But I still have same error. read configure.in, the option is --without-system-sane-header not --without-system-sane-headers I suspect the answers to the next set of questions is more variations on stop using --with-system-libs --with-system-headers and just use ./configure. I suggest that you build OOo at least once from source on a mainstream architecture and distribution, and when you get that working, then try the more complicated task of cross-compiling OOo for ARM on a fringe distribution. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Fwd: Save documents in ~/Documents by default
On Mon, 2010-07-19 at 04:40 -0400, Ricardo Espírito Santo wrote: Hello there, I have been trying this weekend to start my contribution on openoffice. Can anyone give me a push? We already save in ~/Documents by default, no ? At least it definitely seems to under GNOME, pretty sure the xdg dirs spec ended up getting adopted for those settings at least. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Fwd: Is there a dictionary in the format of text file?
On Wed, 2010-07-14 at 10:00 -0500, Peng Yu wrote: I realize that it may be better to send the questions to the dev mailing list. So do I. Thank you! -- Forwarded message -- From: Peng Yu pengyu...@gmail.com Date: Wed, Jul 14, 2010 at 9:54 AM Subject: Is there a dictionary in the format of text file? To: us...@openoffice.org Hi, I'd like to have a local copy of all the English words (including the variants, like, plural form, -ing form, -s form). Since there is spell check in OO, there might be a dictionary file available somewhere. Would you please let me where it is? In theory, those there are bugs in it unfortunately, hunspell's unmunch is supposed to do this, i.e. unzip the dict-en.oxt (or whatever is its exact name) and use unmunch en.dic en.aff and it should stick the -ing, and -s etc onto all the stem words and expand the dictionary+aff files back into a text file containing all variants. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Fwd: Is there a dictionary in the format of text file?
On Wed, 2010-07-14 at 11:13 -0500, Peng Yu wrote: On Wed, Jul 14, 2010 at 10:06 AM, Caolán McNamara caol...@redhat.com wrote: I generated the expanded dictionary. The stderr output is irrelevant to me, right? What do you by in theory? What bugs are you referring to? IIRC some unmunch doesn't give complete or correct results with some .aff files that use hunspell features that didn't exist in the older myspell. e.g. see http://sourceforge.net/tracker/?func=detailaid=3007764group_id=143754atid=756395 Unmunch with flag num not working and there may be others as the unmunch standalone .aff parsing has fallen out of sync with the core librarys one. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Water can !?
On Fri, 2010-06-18 at 11:02 -0400, Kohei Yoshida wrote: While browsing the code with my GSOC student, we've come across many references to WaterCan, which is associated with the SID_STYLE_WATERCAN slot ID. That slot ID appears to be used across all applications. Does anyone have any insight into what that's for? It's not a big deal but not knowing the answer for it is killing me. Always assumed it was Fill Format Mode as in that bucket thing in navigator 2nd from right. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: BigPointerArray, SvPointerArray vs STL containers
On Mon, 2010-06-14 at 11:22 +0200, Michael Stahl wrote: the SvArrays should be replaced by appropriate STL types (mostly vector, i guess, but probably in some cases stacks or deques or something else). deques I think was the best option in general the last time I looked at this. Probably best to ignore the binfilter ones and leave those still using a migrated-into-binfilter svarray family. I thought I had a patch somewhere to do some of the conversion, but I can't find it now. I remember that I didn't go ahead with it at the time because my first cut at it left OOo larger than it was before hand, which was an annoying result. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] RTF Italic/Bold Problem
On Thu, 2010-05-20 at 13:17 +0530, meddictate wrote:
Which files we have to modify for solve this problem.
The rtf parser is split into various bits. Much of it is in
sw/source/filter/rtf while some of the backend bits are in
svx/source/svrtf and svtools/source/svrtf
Typically it gets confused about the { } level that its in
at any given time.
C.
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Building with native open/save dialogs
On Tue, 2010-05-18 at 12:20 +, Kristján Bjarni Guðmundsson wrote: I am building OOO320_m15 on Ubuntu 9.10 and I am having problems enabling the native gnome dialogs for open/save. For some reason the option Use OpenOffice.org dialogs is missing in Tools Options OpenOffice.org General and is enabled by default so the file dialogs displayed are not from gnome. How can I build so this option is visible in Ubuntu? Am I missing some package dependency? grep ENABLE_GTK config.log if this is not 'TRUE' then your OOo is not building any gtk connected parts. Seeing as this is the default its odd you don't seem to have it. Are you sure you haven't passed --disable-gtk as a configure option or something ? You need the gtk development packages of your system installed of course, but that's an obvious requirement. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: [releases] recommended stlport settings?
On Sun, 2010-04-25 at 19:44 +0200, Rene Engelhard wrote: We can only improve things here when we eventually drop the STLport-requirement (and become URE-incompatible on the affected platforms). If we continue to build and package into the install sets stlport on Linux x86, but not actually build OOo itself against it, its quite likely that stuff will work out ok (i.e. legacy binary x86 extensions that link against stlport will continue to work) as there's no explicit use of stl types in the public ure interfaces. Not 100% certain about that though :-) C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] BCP-47 based proposal for IsoStrings, Locale Variants and describing languages ?
On Wed, 2010-04-21 at 17:50 +0200, Mathias Bauer wrote: Caolán McNamara wrote: c) Where we use language and country codes in our xml format we add a language-tags attribute which maps directly to that Variant field. As far as I understand that - it means we have to add support for that attribute into ODF Yes, to be able to save a document and indicate that some text is written in Inuktitut Syllabics (Canada) at the moment isn't really possible, as the only tags we have are fo:language and fo:country are fo:language=iu fo=country=CA would be Inuktitut Latin (Canada), fo:language-tags is the placeholder suggestion I've used in the examples, and in this case would contain fo:language-tags=Cans. and into our core as well, right? In the real world what happens generally is that these Locales and iso-strings are converted into the internal MS based 16bit language id inside our deeper parts of code, so most of our lower code doesn't know about them and converts to/from them through the MsLangId methods. Sounds like a very nice addition, but also like a lot of work. Easy enough really. An example implementation illustrating the changes is at issue 111066. I guess the most important thing is to raise is that IMO we're painted into a corner and that the Variant field is a valuable out as a practically undefined field that could have semantics attached to it to get out of the trap. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] BCP-47 based proposal for IsoStrings, Locale Variants and describing languages ?
On Thu, 2010-04-22 at 15:33 +0200, Eike Rathke wrote: Hi Caolan, ODF 1.2 introduces the attributes fo:script, number:script and table:script. Additionally to *:script attributes ODF 1.2 already introduces number:rfc-language-tag, table:rfc-language-tag and style:rfc-language-tag to store BCP47 language tags if a locale can't be described as a combination of *:language *:country *:script Neat, so no file format changes needed after all. Slots already available. a BCP-47 string of de-DE-1901 becomes Language = de Country = DE Variant = -1901 With the leading '-' indicating the default script? Yup. Why does it need to be reversible? Without that requirement we could drop information after Language-Country starting with '.', leaving Language = sr Country = RS Variant = Latn We should also prepare for transport of full BCP47 tags (see further down), having this mix of script and Unix locale in the Variant field somewhat makes me shudder.. I'd rather use the Variant here such that if the content starts with a capital ASCII letter and is 4 characters it is a script ISO 15924 code, else it is something different, to be defined. This is covered in the other responses, where some hackery exists inside rtl that currently fiddles with the Variant field. 3. comphelper::Locale is very little used, it looks like a good idea to move uses of it over to com::sun::star::lang::Locale and convert it to some calls that operate on that instead and/or merge the unused bits over to e.g. MSLangId. I logged a patch earlier to at least delete all the unused parts of comphelper::Locale and strip it down to the small stub of it that's actually used, mainly just one place in framework IIRC and in one other minor location. Future perspective: the syntax of RFC 5646 allows more complicated language tags, not all can be fitted into Language/Country fields using ISO 639-2/3 and ISO 3166-1 codes. For these we'd have to use some notation to indicate the full BCP47 tag is to be used, having Language=x-bcp47 and Variant=full_bcp47_string might do. Of course this would affect all places that simply take the Language/Country fields as ISO codes. If an extended language subtag (extlang) came into play, the approach of concatenating Language-Country-Variant wouldn't work anymore if we said Variant had to start with the 4 letter script code or '-'. I had imagined that the Language string in a Locale struct would contain the extended language subtag. so that something like zh-cmn-Latn-CN would appear as Language = zh-cmn Country = CN Variant = Latn But I guess after all that this would break anyway as Language is then no longer a ISO-639 code, and without yet-more-processing it would appear as e.g. fo:Language=zh-cmn in e.g. an .odt which I guess is out. Rats. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] BCP-47 based proposal for IsoStrings, Locale Variants and describing languages ?
Our (three) Locale classes, i.e. rtl::Locale, com::sun::star::lang::Locale and comphelper::Locale all have three fields, i.e. OUString Language OUString Country OUString Variant where Language is typically a ISO-639 [*] code, Country is typically in ISO-3166 and Variant is basically an undefined bucket with API documentation copied and pasted from the Java Locale class. We don't have a good way to describe various languages with just Language and Country, typically those that can be written in different scripts. For some cases we're already kluding things a bit with e.g. sh-RS to describe Serbian using the Latin script in Serbia (as opposed to sr-RS to describe Serbian written in the default Cyrillic script in Serbian) and in some cases we don't have a way to describe languages we could support if we had a way to transport that info around e.g. Inuktitut Syllabics Canada (as opposed to iu-CA to describe that language written in the default Latin alphabet which we could currently support) In BCP-47 the examples above could be described as sr-Latn-RS and iu-Cans-CA (http://www.rfc-editor.org/rfc/bcp/bcp47.txt) where basically if the second tag exists (of an arbitrary number of tags) and is four letters long it must be a ISO 15924 script code. i.e. current sr-RS and iu-CA remain valid BCP-47 strings. In parallel with all this the glibc locale string is typically language_country.encod...@modifier_string, where language and Country are as above, while the modifier strings are typically cyrillic and latin for those variants among other more arbitrary ones. e.g. sr_rs.ut...@latin for what would be in BCP-47 style sr-Latn-RS I note here that the rtl Locale parser converts a Unix locale string into a rtl::Locale along the lines of Language = language, e.g. sr Country = Country, e.g. RS Variant = all_the_rest_of_the_string, e.g. .ut...@latin and depends on being able to reverse this conversion back to the the original Unix locale string, i.e. it needs to rebuild sr_rs.ut...@latin from its rtl::Locale structure and the comphelper one does something similar, while the com::sun::star::lang::Locale.Variant seems to be pretty much unused throughout OOo. In our xml format afaics, where the com::sun::star::lang::Locale is basically the structure that backs it, we have just language and country tags. So..., how about we adopt a BCP-47 based approach. i.e. a) Where we are currently describing locales as a string in iso-format we use BCP-47. Currently valid locale strings get to remain valid. b) Where we use a Locale structure, Language and Country stay the same, but we specify a format for the remaining Variant field where it is BCP-based sequence of tags separated by '-'. The Variant field becomes the equivalent BCP-47 locale string for the totality, minus the language and region tags, plus that the first tag entry *must* be a Script Code to ensure forward and backward conversion to an unambiguous BCP-47 string. In this scheme the script tag at the start of the Variant can (and must) be empty to denote the default script. c) Where we use language and country codes in our xml format we add a language-tags attribute which maps directly to that Variant field. i.e. sr-Latn-RS becomes Language = sr Country = RS Variant = Latn i.e. sr-Latn-RS-whatever-foo becomes Language = sr Country = RS Variant = Latn-whatever-foo a BCP-47 string of de-DE-1901 becomes Language = de Country = DE Variant = -1901 de-DE remains Language = de Country = DE Variant = Parsers that want to convert a Unix Locale into the above structure can take, e.g. aa_er.ut...@saaho and make it into Language = aa Country = ER Variant = -.ut...@saaho to give a reversible scheme where the original Unix Locale string can be reconstructed, and for Unix Locale strings which hint at the script in use, we can parse sr_rs.ut...@latin into Language = sr Country = RS Variant = latn-.ut...@latin and remain reversible into the original Unix Locale string, and also provide a non-null script tag which allows continued conversion from the rtl::Locale class to the com::sun::star::lang::Locale one without losing script tag information. The xml format for a style that sets the Language of a paragraph to Inuktitut Syllabics Canada could then use an additional language-tags attribute, e.g. style:text-properties fo:language=iu fo:country=CA fo:language-tags=Cans/ while the Locales string of the spellchecker Locales string can use BCP-47 format, e.g. support iu-Cans-CA C. 1. See #i111019# for the sal issue to parse three letter codes there, and not limit it to two codes. 2. Presumably it would be best to prefer *generating* sh-RS for backwards compatibility, even though accepting sr-Latn-RS 3. comphelper::Locale is very little used, it looks like a good idea to move uses of it over to com::sun::star::lang::Locale and convert it to some calls that operate on that instead and/or merge the unused bits over to e.g. MSLangId.
Re: [dev] BCP-47 based proposal for IsoStrings, Locale Variants and describing languages ?
On Wed, 2010-04-21 at 12:11 +0200, Stephan Bergmann wrote:
On 04/21/10 10:10, Caolán McNamara wrote:
So..., how about we adopt a BCP-47 based approach. i.e.
a) Where we are currently describing locales as a string in iso-format
we use BCP-47. Currently valid locale strings get to remain valid.
get to remain valid: Is it the case that all currently valid locale
strings happen to adhere to the BCP-47 restrictions, so would
automatically be valid BCP-47 strings.
Well, there is one problem. aImplIsoNoneStdLangEntries in
i18npool/source/isolang/isolang.cxx has...
{ LANGUAGE_SERBIAN_LATIN, sr, latin},
{ LANGUAGE_SERBIAN_CYRILLIC,sr, cyrillic },
{ LANGUAGE_AZERI_LATIN, az, latin},
{ LANGUAGE_AZERI_CYRILLIC, az, cyrillic },
Considering the way the various tables work, that means there is one
combination of language of az and country of cyrillic which has
escaped out into the file format as fo:language=az
fo:country=cyrillic, so az-cyrillic would have to be accepted in
addition though it's not valid BCP-47.
Given that, it makes sense to continue to accept as input the other
entries in that above table and aImplIsoNoneStdLangEntries2 +
aImplOtherEntries as acceptable input for an iso-string (though they
never were generated as output). So BCP-47 + some extra grandfathered
tags.
Is the requirement that the first tag entry *must* be a Script Code to
ensure forward and backward conversion to an unambiguous BCP-47 string
really necessary? A langtag w/o language and region parts would be
[script] *(- variant) *(- extension) [- privateuse]
where the syntactic forms allowed for script are disjoint of those
allowed for variant, extension, and privateuse.
The need for conversion from a Unix locale string in rtl to a rtl_Locale
and back again is what bothers me. Following the above protects against
converting a unknown existing or future Unix locale string into a
rtl_Locale which if used anywhere following this convention gives
incorrect results. e.g, there are some glibc locales like zh_TW.euctw so
LANG=zh_TW.Euctw is acceptable
which currently will give
rtl_Locale of...
Language = de
Country = BE
Variant = Euctw
If a future iso-15924 adds Euctw as a script code, then there's a
problem.
The other consideration is that if you enforce a script code as the
first tag in a Variant, it becomes trivial to pull out the script tag
from a Variant string with a two liner without any other processing,
e.g.
sal_Int32 nIndex = 0;
rtl::OUString aScriptSubtag = rVariant.getToken(0, '-', nIndex);
Parsers that want to convert a Unix Locale into the above structure can
take, e.g.
aa_er.ut...@saaho
and make it into
Language = aa
Country = ER
Variant = -.ut...@saaho
to give a reversible scheme where the original Unix Locale string can be
reconstructed
Is reversibility necessary here? I ask because this makes the Variant
contain data that does not adhere to the above BCP-47 langtag w/o
language and region parts.
I feel it is because if we look into sal/osl/unx/nlsupport.c and e.g.
osl_getTextEncodingFromLocale there we use _compose_locale to regenerate
from rtl_Locale a string to pass to setlocale(LC_CTYPE and some other
similar examples in there. So it looks to me that a rtl_Locale that
originates from _parse_locale on a given string has to be convertible
back to that string in order to be useful with setlocale.
C.
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
[dev] heads up on GCC 43560 osl_systemPathRemoveSeparator crash
This GCC issue doesn't affect the vanilla Hamburg Linux builds, but it may affect some distribution builds, depending on their version of gcc. To test, load https://bugzilla.redhat.com/attachment.cgi?id=405919 and run the macro inside the .odt on x86. If it crashes inside osl_systemPathRemoveSeparator then you more than likely have a gcc which is affected by http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43560 The problem is that in x86 -Os mode gcc generates code that always writes back to the length member of the passed in rtl_uString even when it doesn't need to, i.e. a string of length 0 passed in has 0 re-written back to the length member. 0 length empty strings in OOo are optimized to always point to a single shared const empty string. And that const string is in the read-only section so a write back to it causes a SIGBUS. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Are buildbot install sets current sufficient for QA ?
For a given cws, are install sets generated from our public buildbots currently sufficient for Hamburg QA ? Or are there problems using them. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Was : problem building comphelper on MIPS
On Sat, 2010-03-20 at 00:20 +0100, eric wrote: About optimisation, what I have remarked, that the default value is CDEFAULTOPT*=-O2 in solenv/inc/unxlngx.mk And in solenv/inc/unxlngmips.mk, there is : CDEFAULTOPT=-Os Now, reading gcc documentation, I found that the last value passed wins. So we can consider the CDEFAULTOPT*=-O2 wins, because -Os is written before the include unxlng.mk (if I'm not wrong) in unxlngmips.mk. No. Just use export VERBOSE=true to see what command line options are actually passed to gcc. The dmake rule of CDEFAULTOPT*=-O2 says to set CDEFAULTOPT to -O2 if CDEFAULTOPT has not already been set to somethine, and it has already been set to -Os so only -Os will be passed to gcc. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] mysterious headers */inc/segdefs.hxx
On Wed, 2010-03-10 at 13:51 +0100, David Tardon wrote: Hello, does anyone know what's the purpose of the various inc/segdefs.hxx and inc/segdefs_.hxx headers? They doesn't seem to be used anywhere. It smells of win16 64k segments if I had to guess. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] patch submission page for new modules
From m72 editengine was split out as a toplevel dir. Who should we set as patch owner for this one ? C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] new dependency to ant version 1.7.1
On Wed, 2010-02-10 at 11:29 +0100, Juergen Schmidt wrote: configure.cmd configure.in configure solenv/inc/antsettings.mk configure is (of course) generated from configure.in via autoconf so one change to configure.in followed by calling autoconf. I hadn't noticed configure.cmd before, despite it being right there in the root. I have no idea what that's supposed to be. It's clearly customized for a single individual in the windows world to configure a minimal OOo build and probably should be deleted entirely. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Was : problem building comphelper on MIPS
On Thu, 2010-02-04 at 07:48 +0100, eric b wrote: The first thing I found was a missing -fpic flag in the solenv/inc/ unxlngmips.mk -fpic is not missing from unxlngmips.mk. unxlngmips.mk inherits from unxlng.mk and unxlng.mk defaults to -fpic for PICSWITCH so unless it needs to use e.g. -fPIC then PICSWITCH doesn't need to be overridden in unxlngmips.mk C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Was : problem building comphelper on MIPS
On Fri, 2010-02-05 at 09:19 +0100, eric b wrote:
Till now we have tested DEV300_m58 and DEV300_m60, the breakage
took place in the latter but not the former one.
And it was *definitely* the same compiler and tool chain used in both
cases right ? And the error in question is ...
comphelper/source/container/enumerablemap.cxx
{standard input}: Assembler messages:
{standard input}:714: Error: opcode not supported on this processor: mips1
(mips1) `ll $3,8($4)'
This massively looks like a toolchain issue to me and not an OOo one.
e.g. binutils/gcc target mismatch or some foo like that. I imagine that
we're talking about the normal mips o32 abi right ?, the one that gcc
defaults to out of the box for mips-linux-.
There shouldn't be anything really different about mips during the
build until bridges and the bridge test in testtools. e.g. there is
nothing in comphelper that has any mips specific stuff in there.
C.
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Was : problem building comphelper on MIPS
On Fri, 2010-02-05 at 10:30 +0100, eric b wrote: Hi, Le 5 févr. 10 à 10:15, Caolán McNamara a écrit : On Fri, 2010-02-05 at 09:19 +0100, eric b wrote: Till now we have tested DEV300_m58 and DEV300_m60, the breakage took place in the latter but not the former one. And it was *definitely* the same compiler and tool chain used in both cases right ? And the error in question is ... Exactly : both tree on the same machine : rebuild comphelper with DEV300_m57, and DEV300_m58 is ok. Starting m60 - you have the issue, Do we have logs of the exact gcc compile and link calls between pass and fail. Perhaps sometime around there some -Bsymbolic changes went in, or some extra visibility flags (don't think so) were added which triggered the underlying foo. Though it might just have been that some method randomly got large or small enough to run through a different optimization path. mips uses the -Os opt (probably copied from the Intel one originally), which is one of the less travelled gcc optimization routes as -O2 is the typical optimization. Using -O2 is worth a shot as an experiment as well, as are turning off visibility. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: dmake error: while building ucbhelper
On Mon, 2010-02-01 at 11:50 +0100, Michael Stahl wrote: On 01/02/2010 10:19, Stephan Bergmann wrote: On 02/01/10 09:23, Toufique, Imam wrote: Yes, it does. At the beginning I thought -fPIC was not being pulled in, so, I set it manually for g++. Hm, sorry, leaves me clueless. -Stephan me too. the only explanation that comes to mind is compiler and/or linker bug. I rather suspect its a problem with the visibility stuff with that SuSE compiler. i.e. unsetting HAVE_GCC_VISIBILITY_FEATURE and rebuilding that module might work. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] solaris buildbot and stl
DEV300_m68/DEV300_m69 solaris buildbots die in soltools http://buildbot.go-oo.org/buildbot/builders/Solaris-Sparc/builds/1567/steps/Compile/logs/stdio i.e. Error: Could not open include filemap. Error: Could not open include filestring. Error: Could not open include fileiostream etc., seeing as soltools no longer depends on stlport and we now expect there to be a system compiler provided stl available to build the build tools before stlport gets built. Is there anyone able to fix up the buildbot ? C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] ifdef CSET ?
Anyone know/remember what platform/compiler the occasional ifdef CSET sprinkled through the source are for ? AIX maybe ? C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] --enable-crashdump=STATIC
On Wed, 2010-01-06 at 10:23 +0100, Stephan Bergmann wrote: Does anybody remember what --enable-crashdump=STATIC should have been good for? Should it still be relevant? Issue 16528, issue 16633. I think the idea was that using STATIC would link the graphical crash reporter statically against gtk, while true/yes would link it dynamically. There isn't a graphical gtk crashreporter anymore right ?, if so then STATIC/TRUE can go away. As can crashrep/interface.* interface/res.cxx etc. seeing as I only see main.obj mentioned in the makefile.mk there. Also presumably the -lXext -lX11 for MacosX is bogus as well etc. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] patch submission page for new modules
Since the last update of http://qa.openoffice.org/issue_handling/submission_gateway.html various modules have come and go, I've added the new ones and sketched in some guesses in some cases of the best default patch owner. animations - ? apple_remote - ? cui - ? cairo - ? graphite - hdu migrationanalysis - ? nss - jl splitbuild - ? svl - cd l10n - ? vbahelper - npower xsltml - mav If any of those are wrong, or if anyone can fill in the blanks (or want to change the default owner for patches for their group) then those with commit privs can fix their entries with cvs -d:pserver:y...@localhost:2401/cvs co qa/www/issue_handling edit create_submission_gateway.pl perl create_submission_gateway.pl submission_gateway.template submission_gateway.html and commit. Or just let me know and I can do it for you. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] OpenOffice build failed
On Fri, 2009-11-20 at 11:20 +0600, Alexey Serebryakoff wrote: --with-system-headers /home/smooky/projects/openoffice/trunk/connectivity/source/drivers/adabas/BDriver.cxx:34: /usr/include/iodbcunix.h:136: error: conflicting declaration 'typedef int BOOL' /home/smooky/projects/openoffice/trunk/solver/300/unxlngx6.pro/inc/tools/solar.h:60: error: 'BOOL' has a previous declaration as 'typedef sal_Bool BOOL' dmake: Error code 1, while making '../../../unxlngx6.pro/slo/BDriver.obj' Easiest fix would be to remove --with-system-headers to use the unixODBC headers in the OOo tree which don't trigger this. My own system odbc headers have something like #ifndef BOOL #define BOOL int #endif so the issue don't arise. Googling around yours presumably have #if !defined(BOOL) typedef int BOOL; #endif instead, i.e. a conflicting typedef, just like the error says. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Automation-CAT0 tests in EIS are now mandatory
On Thu, 2009-11-19 at 14:55 +0100, Bernd Eilers wrote: Hi there! By request from the QA-Automation-Team the Automation-CAT0 tests in EIS are now mandatory. They must always be started on Windows and Linux and their state should be green before the CWS gets approved by QA or nominated. If you're not in Hamburg, how do you run these tests ?, i.e. how to provide the installation set to the test. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Automation-CAT0 tests in EIS are now mandatory
On Thu, 2009-11-19 at 15:34 +0100, Bernd Eilers wrote: Caolán McNamara wrote: If you're not in Hamburg, how do you run these tests ?, i.e. how to provide the installation set to the test. Well that is unfortunatly a problem which is not really completely solved yet. The only currently possible solution is to first ask a friendly co-developer of yours Polling for internal developers (who mightn't even work there anymore, who knows) is rather awkward and doesn't really scale all that well. How about making the test non-mandatory until its possible for external developers to run it ? Or make it an in-house mandatory rule in the interim. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Library requirements (freetype2 = 2.0 ) not met . . .
On Mon, 2009-11-16 at 20:00 -0500, Albretch Mueller wrote: Hi I think I have all I need: r...@knoppix:/media/hdb2/inst/sw/OO/source/ooxpkgs# dpkg -l | grep freetype ... ii libfreetype6 2.2.1-5+etch4 FreeType 2 font engine, shared library files in order not to have this type of error: checking whether freetype is available... checking for freetype2 = 2.0 ... Package freetype2 was not found in the pkg-config search path. How can I fix this? You simply don't have the development package with the headers and .pc files etc. For Debian (and variants) install libfreetype6-dev C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] How to split VCL testtool out?
On Tue, 2009-10-27 at 16:01 +0800, Zhu Lihua wrote: Hi all, I've built the openoffice.org on a loongson machine, include testtool. I wonder how to split testtool out from the installation set? I need a stand alone testtool. Don't you just need to package... path/to/openoffice.org/basis3.X/program/hid.lst path/to/openoffice.org/basis3.X/program/libcommunili.so path/to/openoffice.org/basis3.X/program/libsimplecmli.so path/to/openoffice.org/basis3.X/program/resource/stten-US.res path/to/openoffice.org/basis3.X/program/testtool.bin path/to/openoffice.org/basis3.X/program/testtoolrc (replacing li with the mips equivalent suffix) C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] build verbosity
On Thu, 2009-10-22 at 08:07 +0200, Frank Schoenheit, Sun Microsystems Germany wrote: The more verbose the output is, the more difficult it is to actually find the line which *caused* the error, not just the error message, simply because all those parallel processes output is mixed. One possibility is to have the bots restart the build after a failure with a non parallel run. Admittedly the downside is that parallel build bugs get lost, but it makes normal ones easier to see, e.g. cd instsetoo_native/util if ! build --dlv_switch -link --all -PX -- -PY -s; then build --dlv_switch -link --all fi C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Linux solenv/inc/.mks merging
From m61 (I think) onwards issue 89237 is implemented to simply remove the linux .mks which are no longer in use and modify the rest of them to stick the arch-independent bits which should be the same across all platforms into a single unxlng.mk and include this from the arch-dependant .mks which override/add arch specific flags. i.e. resolve the mismatched copy and pasting across unxlnga.mk unxlngi6.mk unxlngmips.mk unxlngppc4.mk unxlngppc.mk unxlngs3904.mk unxlngs.mk unxlngi4.mk unxlngm68k.mk unxlngp.mk unxlngppc64.mk unxlngr.mk unxlngs390x.mk unxlngx6.mk So from then onwards only unxlng.mk should need to be changed to add support for a new linux toolchain feature-of-the-moment which should fix all the currently broken things in the secondary .mks where the x86 .mk got changed but the change wasn't made for, say, s390x should get fixed. e.g. -Wl,--hash-style=both is equally available on all platforms, but wasn't applied on s390x. New names are unxlng.mk: Generic toplevel Unix Linux GCC, included by the other ones unxlngi.mk: Unix Linux GCC Intel (X86) 32bit) unxlngx.mk: Unix Linux GCC X86_64 (64bit) unxlngppc.mk: Unix Linux GCC PowerPC (32bit) unxlngppc64.mk: Unix Linux GCC PowerPC (64bit) unxlngr.mk: Unix Linux GCC ARM (32bit) unxlngmips.mk: Unix Linux GCC MIPS (32bit) unxlngs390.mk: Unix Linux GCC S/390 (3[1|2]bit) unxlngs390x.mk: Unix Linux GCC zSeries (64bit) unxlngs.mk: Unix Linux GCC Sparc (32bit) unxlnga.mk: Unix Linux GCC Itanium (64bit) unxlngm68k.mk: Unix Linux GCC M68K (32bit) The output dirs are not affected, e.g. still unxlngi6 not unxlngi C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] openoffice z/Linux
On Mon, 2009-09-28 at 14:06 -0400, Aaron Ehrensberger wrote: Is there any OpenOffice port that has been done for z/Linux? Both 3[1|2]bit s390 and 64bit s390x OOo should basically build and work fine out of the box without much difference from say x86/x86_64/ppc These example rpms at ftp://qa-upload.services.openoffice.org/3.1.0_s390x/OOo_3.1.0_LinuxS390x_install_en-US.tar.gz will probably only work on systems with glib = 2.6, e.g. RHEL-5. I might build some 3.1.1 s390x packages without that limitation and see if I can get them into the normal bouncer vanilla downloads from download.openoffice.org. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] How to compile openoffice?
On Sat, 2009-09-19 at 22:17 -0500, Peng Yu wrote: I run ./configure, but I get the following message. Should I run ./configure again with the option --without-system-stdlibs? Or I can just ignore the warning and go ahead? * - prelinked libgcc_s.so.1, enabling --with-system-stdlibs, use --without-system-stdlibs to override You can ignore this warning. See http://blogs.linux.ie/caolan/2005/02/23/cpio-md5-sum-mismatch/ for details C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] How to compile openoffice?
On Fri, 2009-09-18 at 10:00 -0500, Peng Yu wrote: Fetching dependencies for module libxml2 from solver... failed You don't have quite everything, e.g. see http://download.openoffice.org/source/index.html those dependencies are (I believe) inside the system source package Unknown colorls variable `rs'. ERROR! Could not detect compiler version! try... unset LS_COLORS C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] hsqldb patch (cws dba32h) for OOo 3.2
On Mon, 2009-09-14 at 07:16 +0200, Ocke Janssen wrote: Moin, in cws dba32h a patch for hsqldb will be applied. For those using a system hsqldb on their build environment please apply the patch as well. Thanks. btw, we have multi patch file support now so instead of... PATCH_FILES=patches$/accumulated_patches.patch you can do... PATCH_FILES=patches$/problem1.patch \ patches$/problem2.patch which helps keep patches separate to make it easier to see what each one's intent is. e.g. at the moment the single mega-patch in xmlsec1 is proving a tough nut for me to determine what bits should be applied if the libxmlsec in there was bumped up to a recent version. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] configure cannot find JDK, although gcj 4.3.4 has been installed
On Mon, 2009-09-07 at 17:48 -0500, Peng Yu wrote: Hi, I am trying to install open office from source (OOo_3.1.0_src_core.tar.bz2) But 'configure' gives me the following error. checking whether to build with Java support... yes checking for java... no checking the installed JDK... configure: error: JAVA not found. You need at least jdk-1.5, or gcj-4 However, I have gcj installed. $ gcj --version While it is possible, if you know the exact incantation, to get OOo to build with the *direct* commands of gcj and gij, the very much recommended way is to use commands of javac and java. Generally a distribution has a package along the lines of java-1.5.0-gcj/java-1.5.0-gcj-devel which provide various links and a directory hierarchy that creates a sun-java-alike wrapper around an underlying implementation of gcj/ecj + gij. So what does javac and java say ? C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Moving to bost 1.3?
On Tue, 2009-08-18 at 22:56 +0200, Frank Schönheit - Sun Microsystems Germany wrote: If boost 1.39 proves to be too problematic, We've been building with 1.39 for some time without any noticeable problems except for one little buglet in the function_template header where a #if !defined(BOOST_NO_EXCEPTIONS) is in the wrong place. Patch to fix that is available from http://cvs.fedoraproject.org/viewvc/devel/boost/boost-function_template.patch?view=markup C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Why enable mozilla?
On Thu, 2009-08-13 at 18:12 +, L Duperval wrote: Hi, I compiled without Mozilla support. What features will I be missing? Why would I add it? Digital signature support and and mozilla addressbook integration. Using system-mozilla option regains digital signature support. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] openoffice-3.1 with gcj?
On Sat, 2009-08-01 at 14:39 +0100, lux-integ wrote: I would thus like to know if anyone has built openoffice-3.1 with the gcj instead of suns JDK or openJDK We (Fedora) build OOo (and pretty much everything else) by default with ecj+gij (i.e. java-1.5.0-gcj-devel where javac links to ecj and java links to gij). So it should work out of the box (assuming a setup like above). Any bits that can't compile or need alternative solutions are already setup in OOo to either get disabled on detection of gcj/ecj (e.g. sandbox) or take a libgcj specific workaround. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] build into installation
On Thu, 2009-07-23 at 13:10 -0700, Terrence Miller wrote: P.S. What is the OOo policy on build warnings (there were a lot). We basically ignore all the ones in external projects that are built as part of the OOo build process, e.g. mozilla, neon, curl, libxml2, etc etc. We also don't really care about the ones in some selected directories, e.g. binfilter, and generally do care about all the other ones. There's a --enable-werror configure option which basically turns on -Werror for the directories we care about, warnings in those ones should be fixed. With gcc 4.4. there are a load of outstanding patches for new warnings specific to that version listed at http://qa.openoffice.org/issues/show_bug.cgi?id=96084 C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] how to enable spell-checking
On Thu, 2009-07-23 at 12:44 +0100, lux-integ wrote: --with-package-format=native Normally for e.g. a build that spits our rpms or debs there would e.g. be a openoffice.org3-dict-en-3.2.0-9406.x86_64.rpm rpm or package which consists of a package which injects the English spell checking package into the shared install. You could dig around your install dir to see where dict-en.oxt might have gone in a native format install and unopkg add --shared dict-en.oxt on it in order to install it Or if you can't find it grab one from extensions.openoffice.org C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Help understanding source code
On Mon, 2009-07-13 at 14:02 -0400, Lealdo Delucci wrote: Good Morning, I am working on a project and I was hoping someone could point me in the correct direction. I am trying to write a program that will read Macros from a Microsoft Office document. I found the appropriate file within open office, but I am confused on parts of it. In the source tree, the file is in root-svx-source-msfilter.cxx. I thought maybe someone could point me toward documentation, development notes, or maybe even the people responsible for writing this code or figuring out the algorithms in it. IIRC the streams are compressed with mszip compression, which these days is probably documented if you google for mszip compression, e.g. http://download.microsoft.com/download/5/D/D/5DD33FDF-91F5-496D-9884-0A0B0EE698BB/%5BMS-MCI%5D.pdf The code itself is pre-documentation, so riddled a bit with guess-work, otherwise you'll have to ask a more specific question, the code does have some comments in it which may help. libgsf has a gsf-vba-dump tool which might be exactly what you want if you're looking for a standalone tool that just extracts vba from a pre-xml MSOffice document. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] cws rebase failed
On Sun, 2009-07-12 at 11:28 -0700, Maximilian Odendahl wrote: Hi, I wanted to rebase my cws notes9 to m52, but it failed miserably. What version of svn are you using, I ran into endless misery with rebasing until I gave up on any recent svn version and rolled back to the last 1.5.X release of 1.5.6 C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: [l10n-dev] Localisation moved into own module
On Mon, 2009-06-22 at 18:48 +0200, Ivo Hinkelmann wrote: Hi Eike, Eike Rathke wrote: I guess that for building a language pack the OOo source tree would not be needed anymore, except maybe a few modules, is still a wish for the far future? MBA had the idea to move also all resource source files into a own module but we first need to discuss this a bit further On a not-really-semi-related topic, has anyone had a go at e.g. reseating the subprojects of sdext/swext/sccomp onto using the sdk makefiles and that sdk provided build-system system and move them out of the OOo svn project into top-level independent projects of their own ? C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] oooimprovement thing and BUILD_SPECIAL
On Tue, 2009-05-19 at 14:51 +0200, Joerg Skottke wrote: Hi Caolán, we have a boolean function in VCL Testtool BASIC named hIsOOoImprovementTabVisible() which allows test writers to determine whether the feature is available or not. Nevertheless, presumably oooimprovement has a purpose of improving quality of some kind, so having it in there would be a good thing when making OOo install-sets destined for qa-ing right ? Or is it worthless to qa unless the build being tested comes from an internal build ? Lets put it another way, BUILD_SPECIAL is basically only set in a Hamburg build. Is there any particular reason we *shouldn't* bundle oooimprovement into the install-set of a cws ? C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] oooimprovement thing and BUILD_SPECIAL
On Tue, 2009-05-19 at 16:47 +0200, Bernd Eilers wrote: Caolán McNamara wrote: Now, well does it make sense to activate such feature on any CWS at all? I would say not much as the whole idea here is to get end-user usage patterns not usage-pattern from usages of developers or testers which might differ significantly. Fair enough. I was labouring under the misunderstanding (because I ran the test-tooling from automation and was getting a missing oooimprovement error and then recalled some comment in a previous workspace that underwent qa-ing that various tests had to be skipped/ignored due to its absence) that oooimprovement included some tooling that supported extended generic qa testing. Clearly that's not the case, and the error/warning refers basically solely to a qa test for the correct functioning of the oooimprovement stuff itself, and not that it cannot be property qa-ed. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Problems Printing Document to file via PyUNO
On Wed, 2009-05-13 at 11:59 +1000, Mike Bissett wrote: Looks like that could be the case as I'm getting this error when running the script for a second time against a headless server: File ./DocumentConverter.py, line 165, in module converter.print_convert(argv[1], argv[2]) File ./DocumentConverter.py, line 109, in print_convert document.close(True) uno.RuntimeException: illegal object given! Any pointers on how I can wait for the print job to complete ? I tried hacking in a sleep but that does not seem to help. when running out of headless mode a sleep of 200ms stops any errors. This should work, i.e. using IsBusy to see if the printer is still working. http://api.openoffice.org/docs/common/ref/com/sun/star/view/PrinterDescriptor.html#IsBusy IsBusy = True while IsBusy: #get default printer pprops=document.getPrinter() properties print 'Printer is still busy' #pprops is a tuple, so use python's any, not to be confused #with OOo any, to search for a IsBusy named property IsBusy = any((x.Name == 'IsBusy' and x.Value == 1) for x in pprops) document.close(True) C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Problems Printing Document to file via PyUNO
On Wed, 2009-05-13 at 09:27 +0200, Mathias Bauer wrote: You can pass a Wait property in the arguments of the print call (a boolean value with -surprise! ;-) - value True). Hmm, print's Wait property is documented at http://api.openoffice.org/docs/common/ref/com/sun/star/view/PrintOptions.html but not at http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Text/Printing_Text_Documents or http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Spreadsheets/Printing_Spreadsheet_Documents etc, so I added it in there, hopefully that'll help and there wasn't a very good reason that it wasn't there already. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Problems Printing Document to file via PyUNO
On Tue, 2009-05-12 at 13:27 +1000, Mike Bissett wrote: I'm loading and printing the document like this: ## setup filename option printOpts = self._toProperties(FileName=outputUrl + '.ps') ## print uno.invoke(document, print,(printOpts)) How about... uno.invoke(document, print, (printOpts,)) i.e. add that extra , The root problem of course is that print is a reserved keyword in python requiring the invoke call instead of the natural document.print(printOpts) I'm not sure, but you *may* need to wait for printing to complete before going on to try and close the document C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] default patch owners for modules
On Sun, 2009-05-10 at 16:50 +0900, tora - Takamichi Akiyama wrote: I have just updated the script, attached in an issue 101719. http://www.openoffice.org/nonav/issues/showattachment.cgi/62128/create_submission_gateway_2-2009-05-10.pl Caolán, Could you give it a try and revise it accordingly? Err, wmsfontextract ?, presumably should be msfontextract, and there's a load of entries in there that don't really need to be in there that just clutter things up, e.g. glow never released any actual *code* as far as I know to submit a patch against and so on. So I wouldn't just put in every entry that ever existed in the CVSROOT/modules into that submission page, but instead only the dirs that exist at the moment in svn (and, for the moment at least, leave in the ones that were already listed but have gone away since then). i.e. I added the ones that are missing from a current svn checkout into the list earlier, so from my perspective http://qa.openoffice.org/issue_handling/submission_gateway.html has all the links we currently need, no ? Who should maintain the data included in the script? Developers themselves? Ideally I guess the developers who maintain/don't actually maintain a given module would update it themselves as owner there. Just look for sal. sb is currently assigned. [Module] crashrep porting sal porting sb boot porting I made that speculative change earlier on a gaining forgiveness is easier than gaining permission basis. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] default patch owners for modules
I generally use http://qa.openoffice.org/issue_handling/submission_gateway.html as my launch page for submitting bugs. Where do the default owners for patches there get filled in from ? Is it simply hardcoded into the html of that page ? i.e. I wonder if that page has fallen out of sync with reality in some cases. It definitely doesn't contain all the newer modules that have appeared, e.g. reportdesigner etc., and (no offence intended) mh is listed as the module owner for e.g. sal which doesn't seem quite right. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] default patch owners for modules
On Sat, 2009-05-09 at 13:55 +0200, Frank Schönheit - Sun Microsystems Germany wrote: http://qa.openoffice.org/issue_handling/create_submission_gateway.pl And yes, that's somewhat outdated. Feel free to check out, update, run, and commit the perl script :) Just what I was looking for, I can update that, but the outstanding question then is who is currently seen as the sal maintainer. I feel that in practice it has reverted back to sb, agreed ? but maybe someone else. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] On Modularization ...
On Thu, 2009-04-30 at 16:34 +0200, Kay Ramme - Sun Germany - Hamburg wrote: The above sounds a little like the current single hierarchical build tree with a single toplevel configure script but with a bunch of --enable-prebuild-vcl --enable-prebuild-i18npool etc options and an understandable requirement for a build-helper at that stage (assuming we're talking about per module of per module-bundle pre-build/solvers) More or less, yes. The advantage being the you may build only what you need, so it is not only --enable-prebuild-writer, but also --disable-writer ... I personally wouldn't be too much a fan of that. Its not really what I'd like to use, but more akin to the linux kernel configuration system where everything still lives in one tarball. I'd much prefer to be able to download/checkout (like libICE in modular X) just the vcl source, unpack it, run configure inside it and make it. Installing and building (or downloading the binaries of) if necessary ure.tar.gz, etc. beforehand, rather than effectively downloading/checking out the full openoffice.org.tar.gz and then using ./configure --with-prebuild-ure --disable-all-except-vcl. Hammering OOo closer to emulating the typical project model like gnome/modulear X would be nice for a good few reasons, mostly that all our distro mechanisms are effectively designed around the standalone tarball that configure and build against pre-installed dependencies ;-) C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] buildbot builds vs standard builds
On Thu, 2009-02-19 at 14:48 +0100, Gregor Hartmann wrote: Hi, another problem or rather a question is: what are Buildbots meant to be good for? Fom when they were introduced they had two tasks to perform 1. Test the build under as many different system configurations as possible. 2. Produce builds which are suitable for QA. so the Buildbots seem to rather obey rule #1 now. The question is if we want to neglect this task of the bots in favor of #2 or not. Nah, just to have one build-bot per platform which definitely produces install sets that are the same as come out of the Hamburg build-system. For example the comments in the hunspell4thesaurus eis entries. Poor nemeth seems to have spent about 50% of his time trying to get a good installset for Linux and Windows. He should ideally be able to just whack the cws to the makevanilla buildbots and focus on his real task. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] buildbot builds vs standard builds
On Thu, 2009-02-19 at 17:27 +0100, Jörg Jahnke wrote: ... installing some BuildBots that are as close as possible to the Hamburg RE environment where the milestone builds take place, so that the BuildBots can create builds with a higher reliabiliy. I'd say to go the extra step, and actually have such a buildbot *be* the system which produces the Hamburg milestones builds as well, rather than being a buildbot which attempts to closely match that system. That way they definitely match :-) C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] buildbot builds vs standard builds
On Wed, 2009-02-18 at 12:00 +0100, Stephan Bergmann wrote: I assume that many buildbots use additional configure switches that influence the functionality of the resulting OOo. ... (I do not know where to easily look up which buildbot uses which switches, so I did not bother to check.) Navigating around to see a successful build on a random linux build-bot it should be visible at the top of the configure log section, e.g. looking at a sample line http://buildbot.go-oo.org/buildbot/builders/Ubuntu-7.10-i386/builds/658/steps/Configure/logs/stdio I see just configureswitches='--enable-werror with_jdk_home=/usr/local/jdk1.5.0_12 --with-package-format=deb' for that one. Which would suggest that it is using Sun Java 1.5.0 and no other relevant configure options. So that would be an ideal starting point to example a sample build that comes out of that build-bot with a vanilla one. The default configure options are supposed to mirror the default Hamburg setsolar env as close as is practical (e.g. werror is off by default in configure vs setsolar as there are too many compilers with different warnings in the wider field, and the default it to build the mozilla stuff from the old mozilla source tarball rather than prompt to download the pre-built stuff as there isn't pre-builds available for all archs etc, and on systems where prelink has made libgcc_s.so.1 unusable its automatically dropped from the installs at configure time with a warning) A third factor might be that different build machines have different versions of compilers and linkers installed, I would assume that this has much less influence on the observed variance than the configure switches, however. I suspect it has quite a degree of influence unfortunately. There has been a quite incredible sequence of weird-ass gccs floating around in the 4.0 to 4.1 range. I don't actually think that its a matter that the build bots configure switches are destroying an otherwise flawless set of builds that would be functionally identical to the Hamburg vanilla set. So, in an ideal world, for all the important platforms for which we provide standard builds we should also provide buildbots that produce builds that are (close to) identical functionality-wise to the standard ones. I would love to see someone pick up on this, presumably from the zSun Hamburg infrastructure group. My understanding was that the o3 developer cd was an attempt to provide the same compiler and baseline etc. as used in Hamburg for externals to build OOo against. I never had much success with using it directly, *but* I was able to use that o3 compiler with an old Fedora Core 3 chroot which I've used successfully to generate install sets which pass Hamburg qa without getting caught on irrelevant problems caused by various compiler, binutils, prelink, too-new gtk version, etc problems which absolutely plague efforts to create workspaces which both work on Hamburg test machines with equal results to the baseline build. C. (Of course its not the case that the baseline compiler is some magic compiler free of errors, just that its errors are typically known and the optimization workarounds for the Hamburg compiler get hacked in for that version) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] changing the patch mechanism for external sources
On Fri, 2009-01-23 at 16:10 +0100, Hans-Joachim Lankenau wrote: hi! with the changes done in the cws ause099, each change now will reside in its own patch. for the local module makefiles, the only visible change is PATCH_FILE_NAME - PATCH_FILES. this variable now hold the list (and apply prder) of the existing patches. That's great, much appreciated. It'll really help divide up the changes made by OOo to imported external stuff into the bits done to get it built inside the OOo env, and the individual extra changes done either to simply backport some fixes from newer versions or add new features. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Make component unloading possible again on *NIX
On Thu, 2009-01-08 at 10:08 +0100, Thorsten Behrens wrote: Hi, with the 3.0 Linux baseline being glibc-2.2.3, maybe it's time to enable dlclose() again in osl_unloadModule()? This was #i96683#, but needs to be reassigned to someone. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [porting-dev] building OOo30_m9 error on scratchbox
On Thu, 2009-01-01 at 18:25 +0800, chengxiu...@redoffice.com wrote: Hi all, I am porting OOo3.0_m9 to ARM. I use scratchbox5.0, Its already ported to arm. (i.e. http://qa.openoffice.org/issues/show_bug.cgi?id=83775) but there is one bug in m9, i.e. see http://qa.openoffice.org/issues/show_bug.cgi?id=94905 for the fix, but that isn't related to your current error. Inconsistency detected by ld.so: ../sysdeps/unix/sysv/linux/dl-origin.c: 48: _dl_get_origin: Assertion `linkval[0] == '/'' failed! This error isn't specific to OpenOffice.org, I believe it is related to some problem with parsing $ORIGIN, perhaps under the scratchbox environment, or perhaps a more general case. The people who could help you more with that error are likely the scratchbox people or glibc. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Hardware acceleration
On Thu, 2008-12-25 at 11:04 +0200, Alan Yaniger wrote: Hi list-members, In my build of OOO300_m9, the option: Tools/Options/OpenOffice.org/View/Use Hardware Acceleration does not appear. It does appear in the binary I downloaded from the oo.org webstite. Is there a switch or #define for including this option in the build? Should be basically --enable-cairo for unix platforms IIRC C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] porting to Lemote/mips error
On Wed, 2008-12-24 at 15:38 +0800, zhipeng.zh...@cs2c.com.cn wrote: I porting Ooo DEV300 to Lemote/mips ,debian Linux build ok There is a error while installing info: ERROR: cannot initialize UCB! unopkg failed. There really isn't enough information here to guess at the problem. You need to give more context, or seeing as you ported it I'm sure you can build e.g. bridges with debugging output to see where exactly thing failed. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] cws sync m38 problems.
i.e. Transmitting file data ...svn: Commit failed (details follow): svn: While preparing 'WORKSPACE/officecfg/registry/schema/org/openoffice/Office/makefile.mk' for commit svn: File '/cws/WORKSPACE/svx/uiconfig/layout/delzip' is out of date cws: ERROR: The subversion command line client failed with exit status '1' FAILURE: cws aborted. No amount of svn update is going to clear it, I believe that the problem is files/dirs deleted on trunk and then readded, i.e. svn log svn +ssh://s...@svn.services.openoffice.org/ooo/trunk/svx/uiconfig/layout/delzip I'm not sure what the right way to fix this might be, but *maybe* it is e.g. cd WORKSPACE/svx/uiconfig/layout svn revert * and so on for those un-update-able dirs ? Or does that just store up trouble for the future again ? C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Can an .xcu fragment add a value to a string-list
If there is a configuration property of a tyle oor:string-list I can *replace* the entire value, but is it possible to *add* a value to the string-list with an xcu fragment, e.g. append an entry to say PreferredImplementations in Canvas or to add to an existing UserPaths entry C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Insert-Object-Sound|Video
On Fri, 2008-12-05 at 08:49 +0100, Mathias Bauer wrote: The location problem was fixed by Philipp Lohmann (AFAIK). Indeed, along with adding a gtk main loop and using gtksocket which takes care of about 95% of the problems. Just a titchy bit of 64bit love and a fix for one old remaining bug makes it work fairly universally for me on the linux plugins I have available. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Insert-Object-Sound|Video
So looking into Insert-Object-Sound|Video I see that it really basically also means Insert-Object-Plugin where the plugins are mozilla plugins found in /usr/lib/netscape/plugins Are there any known available mozilla plugin which works with this at the moment ? Under Linux I see that libflashplayer.so sort of does something, i.e. something briefly displayed in the top left corner of the document area, not inside the ole object area. Various other plugins I've tried crash OOo, so I wonder a) Is there much use in having Insert-Object-Sound and Insert-Object-Video as entries in our menus given that Insert-Object-Plugin exists and we already have Insert-Movie and Sound for avmedia support. b) Is it worth fixing the use-mozilla-plugin stuff ?, i.e. remove the crashes, fix up to work on 64bit, look also in modern mozilla plugins location, do something like add a glib/gtk main loop to pluginapp to get new plugins which quite often seem to depend on that existing to function, etc. Or should it just be removed ?. Maybe it is working well on non-linux platforms ? C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] X Y || Z
I'm sure we all know this, but just sometimes get confused when under fire or when adding an additional term to an existing expression. * and / have equal precedence with each other, and + and - have equal precedence with each other. But has a higher precedence than || and has a higher precedence than | so... X Y || Z is equivalent to (X Y) || Z, not X (Y || Z) and X | Y Z is equivalent to X | (Y Z), not (X | Y) Z The most common incorrect pattern is basically along the lines of if (pPointer pPointer-IsSomething() || pPointer-IsOther()) Because I can't get quite enough pain in my life I've checked the results of a gcc 4.3.2 -Wparentheses on all the warnings-free modules and logged patches for the very dubious looking ones where the whitespacing of the expression or the symmetry of terms makes me suspect the intent isn't what is actually expressed. (Though for any expressions where there are about 20+ terms in a potentially ambiguous expression I just closed my eyes) Precedence Reference Tables: http://www.cppreference.com/wiki/operator_precedence http://www.difranco.net/cop2220/op-prec.htm C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: testautomation the effects on the CWS process
On Fri, 2008-10-10 at 06:50 +0200, Helge Delfs wrote: However you might run these tests by yourself and it is of course acceptable to fix these tests if required. What's the (hopefully one line) way to run these tests myself ? Or is this a work in progress and not for use right now ? C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCS Keywords in License Headers
On Mon, 2008-10-06 at 09:20 +0200, Stephan Bergmann wrote: Regarding the tab conversion, I guess such a one-time conversion won't help much unless we could ensure that no new tabs get introduced with new commits. I've long stuck /* vi:set tabstop=4 shiftwidth=4 expandtab: */ at the bottom of the .?xx files that I own in OOo, perhaps something like that plus the emacs equivalent could be mass stuffed into the header region to aid not putting them into .?xx files in the first place And subversion (like cvs) has a precommit hook that can e.g. reject files with tabs in them. e.g. http://wordaligned.org/articles/a-subversion-pre-commit-hook C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] [Sc|Sw|Sm|etc...]DLL::Exit
On Thu, 2008-09-25 at 15:11 +0200, Mathias Bauer wrote: But the Exit method now is never called and IMHO it isn't necessary to do so. The only known problem this creates is that it prevents the detection of memory leaks caused by the objects that now never get deleted. Possibly still the theoretical option of hooking them back into the library unloading scheme of http://udk.openoffice.org/common/man/spec/library_unloading.html Not that we actually attempt to unload any unloadable modules at the moment anyway as far as I can see. There's always the carrot of e.g. loading a writer doc with an embedded starmath equation and after closing it having starmath's globals go away. But no big sweat, I was just wondering if they were supposed to connect to anything right now. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] [Sc|Sw|Sm|etc...]DLL::Exit
On Thu, 2008-09-25 at 23:41 +0200, Mathias Bauer wrote: Caolán McNamara wrote: On Thu, 2008-09-25 at 15:11 +0200, Mathias Bauer wrote: But the Exit method now is never called and IMHO it isn't necessary to do so. The only known problem this creates is that it prevents the detection of memory leaks caused by the objects that now never get deleted. Possibly still the theoretical option of hooking them back into the library unloading scheme of http://udk.openoffice.org/common/man/spec/library_unloading.html IIRC this was not meant to be applied to libraries that inject pointers to objects implemented inside them into other libraries' code, they where meant to be used for libraries where the life cycle of each object can be tracked by UNO reference counting. Well, I only poked around starmath (as I reckoned it would be the simplest user) where the only usage is inside SmDocument_createInstance which is the uno entry point. So that would make it a very good candidate, in that the only way to get trigger the Init is when creating a uno referenced object, so if all the starmath components ref/def-ed the module-used count and if something existed to call the library unloading-foo then it might in theory work out. Not that we actually attempt to unload any unloadable modules at the moment anyway as far as I can see. There's always the carrot of e.g. loading a writer doc with an embedded starmath equation and after closing it having starmath's globals go away. But no big sweat, I was just wondering if they were supposed to connect to anything right now. As we never know if we perhaps will need these methods at some time we should keep them. In this case I'm not wearing my die all unused code hat :-), I was just genuinely interested if there was an existing code-line I couldn't find that called them, especially because I had a hazy memory of an offapp library that might have used them. So, I'd like to keep them too and just, at least in a perfect world theory, see where they should be connected to. That said, in general I'm really sceptical about some day we will use them comments about chunks of code that have no current consumers. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] [Sc|Sw|Sm|etc...]DLL::Exit
So all those ScDLL::Exit, and SmDLL::Exit etc. Where/When are they supposed to be called ? Did they ever get called sometime in the past ? C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] DEV300_m29 compilation warnings
On Fri, 2008-09-05 at 12:21 +0900, Nguyen Vu Hung wrote: 2008/9/5 Eike Rathke [EMAIL PROTECTED]: I have not yet seen all the warning in the dmake log file but first 1 lines of them are quite interesting to look at. Just grep -i warning. Lots of. We don't generally care about warnings in the external projects, e.g. libxml2, libxslt, icc, mozilla, etc. which were imported into the vanilla tree. So there's *loads* of lines there which can be ignored or tracked down in the upstream project. Different versions of gcc also warn about different things too, and there are some platform differences, so e.g. you have some warning: lowering visibility of warnings. They don't exist in a later version of gcc like 4.3.1/4.3.2 so those ones should be ignored too :-) For some of the empty else warnings, the patch at http://qa.openoffice.org/issues/show_bug.cgi?id=93436 might make most of those go away. C - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo 2/3 still using gpc?
On Fri, 2008-09-05 at 16:27 +0200, Thorsten Behrens wrote: On Fri, Sep 05, 2008 at 05:31:27PM +0900, Nguyen Vu Hung wrote: It seems that OOo 2.x uses agg ( 2.3 BSD license if I am not mistaken ) Yeah, but that's disabled for ~all builds - at least the Linux distros I know don't build it. I believe from solenv/config/sdev300.ini that Hamburg vanilla is building against agg, and while distros are probably disabing use of it, its the default for a vanilla configure build as well. Agg is dead for OOo, since it moved to GPL. But is it a dead module ?, canvas still seems to make use of it if agg is not explicitly disabled. Does it profit the vanilla version much to have that old agg in there, i.e. is it worth dropping agg out totally, removing the module and shrinking the vanilla checkout/build/etc down ? C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] gcc 4.3.1 warnings
gcc 4.3.1 has some new warnings.
1. strange forward declarations...
e.g.
class foo::bar;
fix is
namespace foo
{
class bar;
}
2. suspicious ; placement in for/while loops
e.g.
for (i = 0; i 10; ++i);
{
//do something
}
fix is either...
for (i = 0; i 10; ++i)
{
//do something
}
or, if it is intentional, introduce some white-space to silence gcc,
e.g. from
for (int nCount = 0; nCount++ != nIndex; ++nCount, ++p);
to
for (int nCount = 0; nCount++ != nIndex; ++nCount, ++p) ;
FWIW, I've filed individual bugs for all the loops that are probably
wrong.
3. const placement checking.
some const examples.
class foo
{
public:
static void foo(); //3.1
const void foo(); //3.2
int foo() { return 10; } const //3.3
int foo() const { return 10; } //3.4
int foo() const;//3.5
const int foo();//3.6
const int foo() const; //3.7
};
So, while static at the start of a declaration like 3.1 makes the
function static, a const at the start of a declaration instead qualifies
the type following it, so 3.2 says we're returning a const void,
whatever such a thing might be.
So 3.2 is meaningless, it should be void foo(); or the intention might
have been to declare that the method was const, in which case it would
be void foo() const;
3.3. is another pattern occasionally seen in OOo, i.e. the const has
been placed after {} of an inline. What happens here is that the const
is applied to the beginning of the next line. The intention is most
likely to have been 3.4.
3.6 const int foo(); here we are saying that we have a non-const method
that returns a const int. Its *likely* that the intent was that we are
a const method that returns an int. i.e. int foo() const. If the intent
was to return a const int, see 3.7
3.7. returning a const int. Specifying a constness on a fundamental
type returned from a method doesn't really mean anything.
i.e.
const int foo();
int apple = foo(); //ok
is perfectly fine, you can't control the callers receiving variables
constness with it, i.e. you're not enforcing
const int apple = foo();
Contrast against if the method was
const int* foo();
then what is pointed to is const, but not the pointer itself i.e.
const int *baz = foo();
baz = somethingelse(); //ok, I can change the pointer.
*baz = 0; //not ok, can't change the contents
int *bar = foo(); //not ok, constness violation
moving on from there, take
int* const foo();
what is returned is a pointer whose contents *can* be changed, and some
meaningless extra constness on the pointer itself is specified.
i.e. we can still do
int *baz = foo(); //ok
i.e.
int * const baz = foo();
is not enforced by such a signature, and
const int * const foo();
only adds extra constness for what is pointed to, so
const int *baz = foo(); //ok
and
const int * const baz = foo();
is not enforced by this.
So, I've a workspace open where I've fixed all of these warnings in the
modules set as warnings_are_errors.
Where the const has no effect I've made the initial assumption that the
intention may have been to make the method const, and if the method is
already const, or is a function rather than a method, or has some other
reason why the method cannot be const, then I've simply dropped the
extra const.
Anyone unhappy with the above described set of changes I intend to
submit under issue 92941 ?
C.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dev] debug macros in tools and trailing ;
If we look at the debug macros in tools, e.g.
#ifdef DBG_UTIL
#define DBG_ASSERT( sCon, aError ) \
if ( DbgIsAssert() )\
{ \
if ( !( sCon ) )\
{ \
DbgError( aError, \
__FILE__, __LINE__ ); \
} \
}
#else
#define DBG_ASSERT( sCon, aError )
#endif
It's clear that the original intent was that they were to be used
without any trailing ;
e.g.
DBG_ASSERT (something)
not
DBG_ASSERT (something);
but the OSL set of assert *is* intended to be followed with a trailing ;
e.g.
#define OSL_ASSERT(c) _OSL_ASSERT(c, OSL_THIS_FILE, __LINE__)
#if OSL_DEBUG_LEVEL 0
#define _OSL_ASSERT(c, f, l) \
do \
{ \
if (!(c) _OSL_GLOBAL osl_assertFailedLine(f, l, 0)) \
_OSL_GLOBAL osl_breakDebug(); \
} while (0)
#else
#define _OSL_ASSERT(c, f, l)((void)0)
#endif
Needless to say there's a mix of usages in OOo of the DBG_ASSERT and
friends, with a trailing ; the most commonplace, giving us loads of
bare ; about the place which gives the empty body in an else
statement etc. warnings.
Do we want to fix this, or ignore it entirely :-). If it gets fixed,
which do we want, change the DBG_ set of macros to follow what people
are generally doing with them, i.e. make them expect a trailing ;, or
fix the usages to remove the ;.
C.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
