[dev] Re: Off the records (Ubuntu's LO) ... (Re: Re: Genuine OOo in distributions ? (Re: OOo installation packages for Linux, a few (easy) questions
On Mon, 06 Jun 2011 17:28:24 +0200 rony ro...@openoffice.org wrote: [... lots of hostile ranting ignored ...] And by the way, if you wanted to be constructive, why did you not supply a link to the place for reporting it? If it was easy to find such a place, I would have reported it https://launchpad.net/ubuntu/+source/libreoffice see the report a bug link on the right? Alternatively, use the ubuntu-bug commandline tool. It is not different from any other package at all. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Off the records (Ubuntu's LO) ... (Re: Re: Genuine OOo in distributions ? (Re: OOo installation packages for Linux, a few (easy) questions
Hi, On Tue, 07 Jun 2011 12:28:18 +0200 rony ro...@openoffice.org wrote: This is the story for the current Ubuntu 11.04, plain-vanilla installation Which does not include a full libreoffice installation, as this is unfortunately impossible to fit on the install CD along with the rest of the desktop(*). However, if you 'apt-get install libreoffice' you get the full installation. How would I know? By asking on Ubuntus support channels (IRC, launchpad, askubuntu ...). Definitely not by complaining on the OpenOffice.org mailing list. Can we please stop discussing the topic here, as it is way offtopic on this list and we are disturbing the solacing silence found here before. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Off the records (Ubuntu's LO) ... (Re: Re: Genuine OOo in distributions ? (Re: OOo installation packages for Linux, a few (easy) questions
Hi rony, On Tue, 31 May 2011 19:55:44 +0200 rony ro...@openoffice.org wrote: totally off the records for this list, indeed. but maybe nevertheless interesting/amusing: Ubuntu 11.04 replaced OOo with LibreOffice (LO). thats true. Whatever they did, they probably did what they did with their OOo installation in the past with the effect that using the Java interface from the command line does not work (using their unoinfo-output for Java) ! That has nothing to do with OOo or LibreOffice, it did not work any better with OOo. The root cause is that the bootstrap helper makes quite crazy assumptions about where to find the soffice binary. Debian (and thus Ubuntu) does quite a few changes (for example moving jars around), which the original OOo code does not handle too well. unoinfo.sh has no role in this at all -- it is not even packaged on Ubuntu. Instead one needs to deinstall LO, remove ~/.libreoffice in home, get the official LO distribution and install it, then things start to work as was the case in the past with OOo. No, you would need to bootstrap with a ClassLoader having a correct resource path. Never having seen this being reported against LibreOffice on launchpad, it was assumed as not a serious issue. Whining about it on the mailing list of a different project instead of filing a bug is kind of ridiculous still, isnt it? Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: build error
Hi all, On Mon, 07 Feb 2011 20:26:21 +0100 Christian Lippka christian.lip...@oracle.com wrote: this looks like an issue I also had with the new build system. Please try if the patch for issue 116349 helps you. Please note the typo in the patch as pointed out by hjs. It should be $(1) instead of ($1). here is patch as it will be integrated with gnumake3: http://hg.services.openoffice.org/cws/gnumake3/rev/f495584800da Best Regards, Bjoern Michaelsen -- https://launchpad.net/~bjoern-michaelsen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: OOo Windowsbuild with GNU compilers
Hi Jan, On Tue, 08 Feb 2011 12:10:47 +0100 Jan jrheinlaen...@gmx.de wrote: from the website I understand that the standard Windows build requires Microsoft compilers. Is there any plan to move this to using GNU compilers? I am having a really difficult time porting an extension from Linux to Windows because of MSVC features. there is a mingw port maintained by Takashi Ono (tono). But AFAIK there are no plans for OOo to replace MSVC by it. Best Regards, Bjoern Michaelsen -- https://launchpad.net/~bjoern-michaelsen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] pdb files for official build
Hi Knut, I will just crosspost this to the tools mailing list, so RelEng will see it. Keep in mind though, that IIRC *.pdb files contain full source filepaths so there might be indeed issues with releasing them. Best Regards, Bjoern P.S.: How are your ABC Lisp bindings for OOo going. Some public repo somewhere? ;) On Wed, 24 Nov 2010 21:40:44 +0100 Knut Olav Bøhmer boh...@gmail.com wrote: Hi, Thanks for the reply. How can I get my hands on them? I would need them by tomorrow. On 24 November 2010 11:54, Martin Hollmichel m...@openoffice.org wrote: On 11/23/2010 01:16 PM, Knut Olav Břhmer wrote: Hi, Is it possible to get the pdb files for the official build (3.2.1 and 3.2.0) generally speaking, I would say yes, maybe somebody @releng may have a look, if any sensitive data are included in the pdb files and can say about what amount of data we are talking about, Martin - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] gbuild: howto migrate a module [was: cws gnumake2 will soon be integrated ...]
On Tue, 16 Nov 2010 16:50:01 +0100 Björn Michaelsen bjoern.michael...@oracle.com wrote: http://blogs.sun.com/GullFOSS/entry/gbuild_to_boldy_go_where Here is the next one: http://blogs.sun.com/GullFOSS/entry/gbuild_how_to_migrate_a Comments welcome! Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] HG service down?
Hi Pavel, On Wed, 10 Nov 2010 16:51:16 +0100 Pavel Laštovička pavel.lastovi...@blue-point.cz wrote: what has happened with hg.services.openoffice.org? I cannot even ping it. The issue is known and currently under investigation. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] SfxItemPool::Store(): some advice needed
Hi Michael, On Wed, 13 Oct 2010 15:35:03 +0200 Michael Stahl michael.x.st...@oracle.com wrote: [...] because the new *pArr is an STL container, this should be a size_t, not an USHORT. but writing that to the stream would of course be a change of the serialization format. does anybody know where (or if) this method is still called? IIRC from my new_itemsets cws the SvStreams in connection with PoolItems/Pools/ItemSets are only used in binfilter (as you said: who cares?) and in the clipboard code. The second one prevented me from outright killing the SvStream stuff in the ItemSets for now. But as the binary clipboard format is only used to exchange data between OOo and OOo it should not cause too much trouble when you change the serialization (unless one copypastes from two different versions of OOo on the same machine, an rather rare scenario). Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: What is the best desktop tool to browse/navigate the OOo source?
Am Thu, 08 Jul 2010 10:15:58 +0700 schrieb Samphan Raruenrom samp...@osdev.co.th: Thank you :) Hi Samphan, more development resources are here: http://wiki.services.openoffice.org/wiki/Development if you feel something missing, let us know! BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Build Open office 3.20 on window XP
Am Mon, 21 Jun 2010 11:59:41 +0200 schrieb Ruediger Timm ruediger.t...@sun.com: AFAIK tcsh shell is not really supported any more (though it might be on that 3.2 code base - I just do not remember exactly). Could you just try using bash instead? If that is truely the case, we should _really_ make --with-use-shell=bash the default finally and make it _only_ produce a bash environment script. Everything else is confusing as hell to newcomers. Actually, we should change the default by now, regardless of how well supported tcsh is: http://qa.openoffice.org/issues/show_bug.cgi?id=112591 Any volunteers? Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Building the Source Code
Am Tue, 15 Jun 2010 10:47:07 -0700 (PDT) schrieb Matt Wis mattwi...@yahoo.com: I have installed Cygwin and the five modules listed at http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Windows. I cannot run configure. When I run ./configure, it says bash: ./configure: No such file or directory. Well, you should change to the directory with the source code before running the configure command. configure is a script in the root directory of the checked out source tree. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: about oov build
Am Wed, 16 Jun 2010 15:32:54 +0800 schrieb wangxiang wangxian...@gmail.com: *But another question comes back : I can't find the .o or .so libs in the folder /opt/openoffice.org3/program (There's only an libnpsoplugin.so in the folder )* Is that right ? Yes, most libs are in /opt/openoffice (the middle layer, see http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/Three-Layer_OOo) *Because I want to build the sw module with debug information, and replace the existing libs with the new build libs* Well, you should not need to do that with a machine-wide installation. You can either set: export FORCE2ARCHIVE=true or export PKGFORMAT=installed to get a tarball that you can simply unpack an run anywhere, or to get an runnable installation directly in the output tree of instsetoo_native (http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Linux#cite_note-Foot6-5.) Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: SfxItemSet assumptions and assertions
Am Wed, 16 Jun 2010 10:11:25 +0200 schrieb Mathias Bauer nospamfor...@gmx.de: BTW: I don't remember if any of the two ItemSet implementations returns an VoidItem in a GetItem call for a disabled item or if NULL is returned then. IMHO it always should be the latter. Getting a void item the old implementation returns: - a state disabled and leaves the item pointer unmodified in GetItemState - a NULL item pointer in GetItem - a pointer to the void item and fires an assertion (triggered on which id == 0 _OR_ type == SfxVoidItem) in Get Getting a void item the new implementation returns: - state disabled and leaving the pointer unmodified only on which id = 0 in GetItemState - a NULL item pointer on which id = 0 in GetItem - a pointer to the item in Get Void items with a which id set to the which position it is in in the itemset are treated just as any other item. Assertions are mostly pushed to the point where such items are put in the set, not when they are extracted -- when it is too late already. Back to your primary topic. If we identify the places where a VoidItem with ID != 0 is put, and if the developers state that this is by intent, we can remove that assertion and make putting VoidItems with ID != 0 a valid action that does not disable that item. True. Still somewhere code may lurk, where a void item is put with a which id set and expected to work as a disabled state. For example IIRC doing a SfxItemSet::Put(SfxVoidItem(4711)) will result in SfxItemSet::GetItemState(4711, false, NULL) returning a disabled state in the old implementation, but not in the new one. So there are three cases. The developer intended: - the behavior of the old implementation (which would be abuse of the interface) - the behavior of the new implementation (which would be a bug) - any behavior, because they make no difference in the given scenario. A migration path could be as follows: We have a aborting assertion on putting void items. Every such call either gets replaced by: - an explicit DisableItem call - or an explicit (new) PutVoidItem call (with the which id of the void item set to the which id of the position in the set) After we got rid of all the assertions, we might remove the PutVoidItem call and allow Put to accept void items with a valid which id. The question why ItemSet::Put must allow that nWhich differs from the item's which is still open. I assume that it's related to different pools having different WhichIds for the same item. But knowing it for sure would perhaps allow us to define a less fuzzy interface. ACK! Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: about oov build
Am Wed, 16 Jun 2010 16:22:13 +0800 schrieb wangxiang wangxian...@gmail.com: Thanks, I just want to build some modules like SW with the debug partial build, and replace existing libs to get some debugging But I can't find the .o or .so in the installation folders. In my fedora12, it's /opt/openoffice.org3/program/ and i follow your suggestions and find the programs in the output tree sub-folders openoffice.org3/program/ But there're still no other libs in the folder /opt/openoffice3/ is the brand layer, you need to find the basis layer. On my machine (gentoo) it is at /usr/lib/openoffice/basis3.2/program on other distro it might be a different location. Ask your friendly package manager. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: BigPointerArray, SvPointerArray vs STL containers
Am Tue, 15 Jun 2010 09:18:45 +0200
schrieb Jan Holst Jensen j...@biochemfusion.com:
On 2010-06-15 09:06, Bartosz wrote:
By the way.
After replace svArrays by STL containers, in some cases I observed
boost of performance.
For example:
for (USHORT i = 0; i aEntries.size(); ++i)
{
if (aEntries.at(i).aFntFmt == rFntFmt)
{
aRes = aEntries[i].aId;
break;
}
}
is much faster than:
USHORT nCnt = aEntries.Count();
USHORT i;
for (i = 0; i nCnt 0 == aRes.Len(); ++i)
{
if (aEntries[i].aFntFmt == rFntFmt)
aRes = aEntries[i].aId;
}
If you're about to optimize then try the iterator-version of above as
well. Something like (not tested, off the top of my head, and I don't
know the actual type of aEntries):
EntryType::iterator end = aEntries.end();
for (EntryType::iterator i = aEntries.begin(); i != end; i++)
{
if (i-aFntFmt == rFntFmt)
{
aRes = i-aId;
break;
}
}
In some of the code that I work on (not OOo, but another C++ project)
I have seen a very nice performance boost by switching from
array-style subscripting to iterators.
Having measured performance on container access ad nauseum for
new_itemsets I can only warn you about such generic statements: For
example the new_itemsets cws seems to be 2-8% faster for loading and
saving on unix, while seeming to be ~8% slower on loading on windows
currently. So while measuring with callgrind is helping, it is only
part of the truth -- especially since it is partially synthetic. Also
measuring on a high-end i7 developer machine might be misleading,
since the scenario were we care about performance (meek netbooks etc.)
have completely different CPU-caches etc., resulting in possible
completely different performances.
Best Regards,
Bjoern
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: BigPointerArray, SvPointerArray vs STL containers
Am Mon, 14 Jun 2010 17:32:27 -0400 schrieb Andrew Douglas Pitonyak and...@pitonyak.org: Changing out SvArray, will fix this long standing bug, which will bring great joy and happiness to my life. http://www.openoffice.org/issues/show_bug.cgi?id=84159 Getting rid of SvArray might not be enough alone to fix this, but it would be a big step in the right direction. Please also have a look at the work in cws new_itemsets which tries to get rid of the old SfxItemSet implementation and replace it with stl container-based stuff whereever possible. Changing such a fundamental datastructure is not easy at all, but the new implementation is mostly stable by now -- only a few minor glitches remaining. Gotta have to have a look at the stuff with somebody from the calc team. Any voluteers? Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: CMake
On Fri, 11 Jun 2010 18:55:59 +0200 Michael Stahl michael.st...@sun.com wrote: We did attempt to create non-recursive makefiles for CMake, and they are less recursive than they once were. However, we found it impossible to handle implicit dependencies of generated source files without using recursive calls to make. If you have a solution for that, we would be very receptive. i believe the gbuild system is designed so that GNU make will restart itself automatically in such circumstances. but i don't know how that works, maybe Björn will explain it... Hi all, see http://www.gnu.org/software/automake/manual/make/Remaking-Makefiles.html#Remaking-Makefiles for details: To this end, after reading in all makefiles, make will consider each as a goal target and attempt to update it. If a makefile has a rule which says how to update it (found either in that very makefile or in another one) or if an implicit rule applies to it (see Using Implicit Rules), it will be updated if necessary. After all makefiles have been checked, if any have actually been changed, make starts with a clean slate and reads all the makefiles over again. (It will also attempt to update each of them over again, but normally this will not change them again, since they are already up to date.) So this is done by including an not yet existing file and providing a rule for it -- GNU make will take care of the rest. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] branchmirror extension
Hi list, playing a bit with hg I found it quite it quite easy to create extensions. First experiments resulted in the branchmirror extension which lets you update a set of branch repos (specified by regular expression) with one command, using not too much bandwidth. You will find the extension here: http://mercurial.selenic.com/wiki/BranchmirrorExtension Comments, ideas etc. welcome. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] How to use DBG_foo?
On Thu, 01 Apr 2010 16:40:11 -0400
Terrence Enger ten...@iseries-guru.com wrote:
Greetings,
What does it take to use, for example, the DBG_ASSERT function defined
in debug.hxx? I have poked around on the wiki without success.
I have added enough #include lines to get the file to compile, but now
the link step is failing with undefined references to DbgFunc() and
DbgOut(). I see that these functions are bound into libtlli.so, but
how do I tell the build system to--pardon the pun--make the link?
In general -- dont do it. As Michael Stahl pointed out on:
http://wiki.services.openoffice.org/wiki/Writer/Code_Conventions
DBG_* is defined in module tools, and therefore evil by definition
Consider using OSL_ENSURE and friends from sal/inc/osl/diagnose.h
instead.
If you still want you use the evil old tools asserts, you would need to
find the makefile where the linking gets done (most on the time
${MODULE}/util) and add the tool lib to the linked lib like this:
SHL[0-9]STDLIBS+= $(TOOLSLIB)
You would also need to make sure that your module depends (directly
or indirectly) on the tools module in the prj/build.lst file.
Best Regards,
Bjoern
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Re: OpenOffice.org Product Development
On Wed, 31 Mar 2010 12:52:18 +0200 Rene Engelhard r...@openoffice.org wrote: a stronger community means actively involving hughe parts of the community. which you don't. there's still many sun-internal decision just posed to the community as a fact everyxone has to live with. Who is you here? Sun contributors are not the Borg and in a community they should be treated according to their individual merits and vices and not be hold in kin liability. There's still bugs not fixed or cared about because it doesn't affect *you* (but only people outside) So you want to have control over the way that Sun manages its resources? Thats not how it works in _any_ OSS project. If you would stomp into #gentoo, #debian or #ubuntu and request your personal itch to be scratched you would be laughed out the door. Well, on ubuntu you might be offered a support contract, but that is different from what you are suggesting here. Or patches lingering around for no reason because no one cares about. That would be a different issue. But there are also non-Sun domain developers, so this is not specific to Sun contributors -- its plain old lack of ressources. That's not true. At least not for all cases where stuff ends up in go-oo. Or to put it another way: It has been true for at least quite a few cases. Finally, I do not like statements implying You are at Sun and thus not part of the community.. Actually, that is quite an unfair discrimination. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Re: OpenOffice.org Product Development
On Wed, 31 Mar 2010 13:52:11 +0200 Rene Engelhard r...@openoffice.org wrote: How is patch -pX lack of resources? How is telling people how they need to change stuff to get a patch (which works for everyone else except Sun and is needed there) finalized to get integrated a resource problem? (The fix I have in mind is a triviality for someone who knows how to add/hide stuff in the Options dialogs) First the issue must be understood(*), then the patch need to be reviewed, it must build warning-free on all platforms against baseline and be QA'ed. You cannot simply apply 10 patches and be done in half an hour. So you might consider our processes unsuited for our needs -- if you do so, that might be discussed. But that is per se a completely different discussion from the distinction between Sun and Non-Sun contributors. Best Regards, Bjoern (*) Which is not trivial at all: Some patches change behavior they consider as a bug, while others would consider the same as a feature. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: OpenOffice.org Product Development
On Wed, 31 Mar 2010 22:10:54 +0200
Sophie sgautier@free.fr wrote:
The unbalanced was between the mail and the disclaimer on the wiki.
Sorry that I didn't explain myself better adding confusion on
something I found important. (BTW I never read Eric Bachard mails
since almost 2 years or really by accident, this is irrelevant to my
eyes). Björn has done a very important work and we should be all
really thankfull to him. [you know there is always a but, here it
comes ;-) ] But, when I saw this warning at the top of the log of the
release minutes page [1], I thought of a contributor, where English
is really not his beloved language. He will go away asap and won't
contribute anymore once he has tried to read/understand this message.
This not the goal of the wiki to discourage contributions... I will
discuss this on the doc project when I have some time, but I wanted
to clarify my not so balanced assertion.
Well, I when adding the {{PageIgnoresWikiGuidelines}} template to a
page I take a look at the log. The creators of those pages mostly
english speakers and very involved in the project, so I could assure
they knew about the stuff going on with the wiki cleanup or knew where
to complain to.
However, the newcomers on the wiki are indeed a problematic case: We do
not want to scare them away, OTOH the cleanup showed me most of
litter that has piled up (incomplete page, no context, no links, no
category and sometimes nonenglish) was created by people
making their first, only and incomplete contribution. Such pages do
more harm than good because they mess up the Wiki and render the search
useless with meaningless results.
When editing content on the wiki, it has always been quite
clearly below the edit box: Please note that all contributions to
OpenOffice.org Wiki may be edited, altered, or removed by other
contributors. If you do not want your writing to be edited mercilessly,
then do not submit it here.
One thing we might consider is to link from the contribution guidelines
to Communication and IRC Communication and ask people to get in
contact before editing.
Actually, Im gonna add that to the template and the guidelines now.
Best Regards,
Bjoern
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
[dev] Wiki Cleanup: Mission Accomplished (Mostly)
Hi List, the Wiki Cleanup has been almost completed. There are just seven pages left in: http://wiki.services.openoffice.org/wiki/Special:UncategorizedPages If you can remove those, please do so. Also note the new Guidelines at: http://wiki.services.openoffice.org/wiki/Wiki_Contribution_Guidelines All previous guidelines now refer to that page. Please stick to them when creating new content or when updating old. Pages that ignoring the guidelines will be dealt with more vicously from now on (read: they might just be deleted). Some of the categories are still overflowing with pages. Please note that the administration guidelines[1] say: Dont assign a page to multiple categories if one is an subcategories of another. Just use the most specific category. This eases reordering and reorganisation of categories. I already sorted out the Development (which had more than 200 members) and Writer categories, by creating subcategories and moving the content into them. A category with more than 100 members rarely helps anybody. Other categories still need help. The dev projects are asked to take responsibility for the pages in subcategories of Development and its subcategories. Please take a close look at the pages in the following categories: http://wiki.services.openoffice.org/wiki/Category:Calc (113 members) Please create subcategories and move the pages into the more specific subcategory. Best Regards and thanks to all who helped out, Bjoern [1] http://wiki.services.openoffice.org/wiki/Wiki_Administration_Guidelines - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Trying to build and hack efficiently
On Sat, 20 Mar 2010 20:45:07 -0400 Rémy Roy remy...@remyroy.com wrote: I'm using Ubuntu 9.10 with the DEV300 branch. I've having some troubles building with the PKGFORMAT=installed option. I can build successfully but in the end my LOCALINSTALLDIR only contains an openoffice.org directory. It seems like it is missing the openoffice.org3 directoy where I should be able to find the executables. Hi Rémy, see http://www.openoffice.org/servlets/ReadMsg?list=devmsgNo=25968 Please consider opening an issue for that (if only for the fact that then there will be a place to point people to). But I guess it wont get high priority since you can either leave LOCALINSTALLDIR unset and build directly into the output dir of instsetoo_native or you use FORCE2ARCHIVE and untar the result to you preferred location. Note that PKGFORMAT=installed has been removed from the Building Guide exactly because of this weird behavior. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Coding St{andards|yle}
On Wed, 10 Mar 2010 14:57:12 +0100 Thorsten Behrens t...@openoffice.org wrote: sure, I buy those. Would then be worthwhile to re-def the types you listed in terms of their C/std:: counterparts. Can do that. sal_sChar is indeed unused, sal_uChar not so much (but there should be a trivial 1:1 mapping). Or better even, mass-move things like sal_Size/PtrDiff over to size_t etc. Moving things over to std. c++ is of course preferable. But at least we should kill of defines that are unused and of questionable value (like sal_sChar) _right_ _now_ as that is easy to do and otherwise they will be used sooner or later. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Coding St{andards|yle}
On Wed, 10 Mar 2010 15:56:37 +0100 Stephan Bergmann stephan.bergm...@sun.com wrote: Re wincing at obviousness of matching range: How is that any different for plain int (with INT_MIN--INT_MAX range) vs., say, sal_Int32 (with SAL_MIN_INT32--SAL_MAX_INT32 range)? Because our interfaces consist of sal_* types and users of interfaces might rely on the implicit guarantee that a component can handle the full range of the type. Bugs because some code uses some odd 16 bit integer internally are really annoying (and not as uncommon as one might guess *cough* writer core *cough*). Of course, using sal_* types internally does not solve the range problem (multiplying two sal_Int32 for example), but still ... BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Problem with building Open Office from mercurial
On Tue, 16 Feb 2010 00:21:36 +0100 Lukasz Szczygielek lszczygie...@gmail.com wrote: I have a Linux Fedora 12 64 bit. After a configure and bootstrap and source LinuxX86-64Env.Set.sh I discovered the problem. On the page I read that after this steps I should make: dmake but then I had: Checking module list build -- version: 275224 Fetching dependencies for module testautomation from solver... failed Fetching dependencies for module packimages from solver... failed Fetching dependencies for module postprocess from solver... failed Fetching dependencies for module l10n from solver... failed WARNING! Project(s): testautomation packimages postprocess l10n Hi Lukasz, looks like this is the output from the check_modules rule which does call build.pl --checkmodules. build.pl --help says, that does check if all required parent projects are availlable[sic]. Can someone from RelEng help out with a description a bit more verbose? For now I just changed the description in the Building Guide to do: cd instsetoo_native build --all which is what most devs actually do. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Problem with building Open Office from mercurial
On Tue, 16 Feb 2010 11:43:41 +0100 Stephan Bergmann stephan.bergm...@sun.com wrote: On 02/16/10 11:27, bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: For now I just changed the description in the Building Guide to do: cd instsetoo_native build --all which is what most devs actually do. Not smoketestoo_native? Valid point, Im feeling a bit guilty. However, since I dont like those various windows popping up on my desktop, I usually do a build, and only after that is successful, I hassle myself with setting up a vnc-session to run the smoketest in. I should script that, then I could go directly to the smoketest. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 10:30:59 +0200 Rich ric...@nakts.net wrote: speaking as a user here, not a coder - if software can continue with operating, it should. yes, it should warn me, but it should run as long as possible, either allowing me to save the document, copy data out of it or whatever. We are talking about product builds, so this does not effect and affect (pun intended) end-users. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 13:12:08 +0200 Rich ric...@nakts.net wrote: (non-product, i assume ?) ahem, yes. if the plan is to use these non-product builds for developers only, then i stand corrected and have no opinion on the issue :) Thats the plan as I understood Stephan (didnt he clarify that already in one of his followups?). BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 12:43:29 +0100 Malte Timmermann malte.timmerm...@sun.com wrote: -1 for discussing here whether or not QA should use non-pros, because it IMHO has absolutely no influence on how assertions should behave. And if you want QA to use non-pros, they for sure would give up quite soon when assertions always abort. With assertions being assertions and give up meaning reporting it, thats exactly the desired behavior. Current situation: - assertions might be anything from a informal I didnt expect this external data to a critical internal state corrupt Desired situation: - assertions are only internal state corrupt messages and should abort - everything else is tracing, logging For example, Frank is claiming his asserts are all serious issues and thus shouldnt be degraded to mere traces. So keeping his asserts as assertions, even if they abort should not scare anyone, right? Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 12:34:33 +0100 Christian Lippka christian.lip...@sun.com wrote: So you see OSL_ASSERTS from your code, but you never see asserts from code that your code uses. Or things you break with your code in other places. Im covering very broad ranges of modules with DEBUG=true, not just the module were I changed code. Can you elaborate on the issues that bother you? Various little annoyances, each not taking long to debug, but those are adding up. And I may be wrong but DEBUG=true in pro does not give DBG_ASSERTs. Which is a bug. DBG_ASSERT should be killed if favor of OSL_ASSERT anyway, or is there any valid use for having those two? Assertions are different to build breakers enforced by the changes for warning free code. You can very easy verify that you have not introduced any compiler warning with your changing by simply build the complete office (yes not 100% I know, but you can be very sure). But you can never be 100% sure that you didn't introduced assertions since you can't check every code path there is that may be affected by your changes. Therefore assertions will pop up in the master and an abort will render non pro unusable so people will stop introducing them. Assertions should be tested with the common tests (cwscheckapi has decent code coverage) preventing the non-pro master to become unusable. Assertions should be visible enough to get reported and rare enough to allow usual testing and development on the nonpro builds. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 13:10:01 +0100 bjoern michaelsen - Sun Microsystems - Hamburg Germany bjoern.michael...@sun.com wrote: Current situation: - assertions might be anything from a informal I didnt expect this external data to a critical internal state corrupt Desired situation: - assertions are only internal state corrupt messages and should abort - everything else is tracing, logging On a second thought: Frank is afaid his asserts will get lost in all the OSL_TRACEs we have today, Stephan wants assertions to be assertions. Proposal: - Make all current OSL_TRACEs to a new OSL_TRACE_VERBOSE (available by OSL_DEBUG_LEVEL2 or something) - Make all current OSL_ASSERTs and DBG_ASSERTs to OSL_TRACEs - Keep OSL_ASSERT for real asserts that abort (and creates an P1 when firing on a master) The migration will not change the behavior much but allows the introduction of real assertions. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 14:38:18 +0100 Philipp Lohmann philipp.lohm...@sun.com wrote: The obvious optimization for that process would be leaving things as they are and introduce an OSL_ASSERT_ABORT for those who really want that. still one would need: - to get rid of DBG_ASSERT, because it makes absolutely no sense to have both DBG_ASSERT and OSL_ASSERT). - to move all the non-informal assertions up to OSL_ASSERT_ABORT. And Frank and Christian should be the first to do that for their assertions, if those are, as they claim, only reporting seriously messed up internal state unlike those chatty noncritical observations us other devs seem to use assertions for. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 17:31:18 +0100 Christian Lippka christian.lip...@sun.com wrote: If we make the office crash in non pro than there will be never a chance to get the qa to work on non pro again. Depends. If we make the master crash on tests in every milestone, sure. As said before an aborting assertion should only be used for corrupt internal state. If you notice a pointer to dead objects flying around or invalidated iterators that are used it is _Good_ to crash on non-pro, simply because continuing from there is pure luck (and its so much more fun to debug if dead objects have devastated the program state by a decent fandango on core). Also, an assertion that aborts hinders my work with the office as long as the assertion is not fixed. One abort assertion in writer with 100 people working on the writer causes one to fix the issue and 99 to idle until he has finished and commited the fix. If you like your assertions to abort, you can press the cancel button. It not difficult to temporarily comment out the one assertion that went past the tests on the cws and on the master until that P1 is fixed. IIRC, Stephan said on FOSDEM that he intends to get tests to run on the master too. Assertion-free execution of those should be part of that. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Correction in OO.o Base
On Tue, 09 Feb 2010 17:12:23 +0100 Svatopluk Bláha svatopluk.bl...@quick.cz wrote: Now, with which conditions I can obtain access to source code? Hi Svatopluk, see http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide for getting started. Best Regards, Bjoern Michaelsen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Test Cleanup
On Mon, 14 Dec 2009 15:06:45 +0100 Stephan Bergmann stephan.bergm...@sun.com wrote: Hi all, I just embarked on a new project, namely to clean up and consolidate the various test frameworks and corresponding tests available in the OOo build environment. ... Comments on all of this are, of course, very welcome. Yay! Sounds like another great step forward for the development environment. Best Regards, Bjoern Michaelsen -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Building OpenOffice.org with GNU make
Hi Lists, The Build Environment Effort Team(1) has implemented a proof-of-concept on how to build OpenOffice.org using GNU make. The rationale for this is explained in this blogpost on GullFOSS: http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu The Build Environment Effort Team is carefully optimistic that updating the build system in this way would benefit the development of OpenOffice.org. Your questions, opinions and ideas about this topic at welcome. You are invited to discuss a possible move to GNU make and its implications on the mailing list d...@tools.openoffice.org. I will try to answer questions ASAP. Best Regards, Bjoern Michaelsen (1) http://wiki.services.openoffice.org/wiki/Build_Environment_Effort -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] How can I build source code using VS 2008
On Wed, 02 Dec 2009 09:48:21 +0800 Arron Xiao arron.x...@gmail.com wrote: I intend to build openoffice source code using VS 2008 C++, However, I cannot find any resource about it on your web site. Can you tell me relational link about it or give me some suggestion? May I ask where you looked (which pages you crossed) when searching for the resources on building OOo? We might consider adding a link to the Building Guide from there. Best Regards, Bjoern Michaelsen -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] interested in joining you
On Tue, 17 Nov 2009 19:56:42 -0800 (PST) Ranjeet Jaiswal jaisranj...@yahoo.com wrote: Hallo sir, I am an engineering graduate from university of Allahabad. Interested to joining openoffice.org Please tell me how I can start with you. Welcome Ranjeet, it depends on what tasks you want to perform. For development of OOo itself see: http://wiki.services.openoffice.org/wiki/Development For development of extensions to OOo see: http://wiki.services.openoffice.org/wiki/Documentation/DevGuide http://wiki.services.openoffice.org/wiki/OpenOffice_NetBeans_Integration to get started. see: http://extensions.services.openoffice.org/ for examples on what can be done with extensions for OOo. Best Regards, Bjoern Michaelsen -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build System and visibility
On Tue, 17 Nov 2009 10:32:21 +0100 Frank Schoenheit, Sun Microsystems Germany frank.schoenh...@sun.com wrote: At least we'd need a makefile-clause for setting a default, /me thinks. For instance, for libs exporting the usual three UNO entry points component_*, I would like to have a make everything private directive, plus a PUBLIC statement for the three functions. The default would be everything private. For other libs, which mainly provide tools for client code, a make everything public directive would be useful. These tools libs fall in two categories: - either they are small helper libs, in which case it is not much effort to make every PUBLIC explicit in the source. - or it is one of the bigger framework libraries, in which case you would want to only export what is absolutely needed - default: everything private. Which means that you'd still need 2 of the 3 mechanisms, and the only thing you could spare are the map files. Not sure this would be worth the effort. I do not think that we still have that many libs that are not explicitly marked PRIVATE/PUBLIC on the function. So it would be only about those few renegade libs that do not follow the convention. A very important sideeffect would be that the visibility of a function can be seen directly in the source, not by: - the source - the mapfile - the makefile - That would be a huge improvement in readability. Best Regards, Bjoern -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] configure: error: Failed to find some (perl) modules
On Sat, 14 Nov 2009 19:17:40 -0500 Albretch Mueller lbrt...@gmail.com wrote: I am trying to run config like that (from within a script) but I an stumbling on some missing perl modules: [...] checking for perl... /usr/bin/perl checking the Perl version... checked (perl 5) checking for required Perl modules... Can't locate Archive/Zip.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at -e line 1. BEGIN failed--compilation aborted at -e line 1. configure: error: Failed to find some modules I thought --enable-verbosity was going to give me more information but there are a lot of packages here: http://packages.debian.org/stable/perl/ which ones do I need to install in order to configure OO? in general, see: http://wiki.services.openoffice.org/wiki/Category:Distribution-Specific_Build_Instructions for the package names of the prerequisities on different distros. Best Regards, Bjoern -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Build System and visibility
Hi List, again some stuff from the Build Environment Effort(1). While figuring out the way we build libraries with the OpenOffice.org build system it became apparent that we seem to have way to many redundant ways to set the visibility of functions. From the top of my head: - map files - explicitly setting a compiler flag in the make file - XX_DLL_EXPORT/XX_DLL_IMPORT/XX_DLL_PRIVATE and friends However, using the XX_DLL_PRIVATE and friends should be enough for everyone, right? So, it should be possible to simplify the build by only using XX_DLL_PRIVATE and friends, or does anybody see a use case that is not covered by it? If so, I would like to hear it ... ;-) Best Regards, Bjoern (1) http://wiki.services.openoffice.org/wiki/Build_Environment_Effort -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Getting rid of implicit dependencies on default_images
Hi List, While working on the Build Environment Effort(1), we stumbled over the implicit dependency of all modules generating resource files on default_images. The resource compiler digs into the default_images directory for the files specified in the *.src/*.hrc files. However, since there is no need for rsc to actually read the file contents when generating *.res files, the dependency is much heavier than needed. After all, everything rsc needs to know is _if_ there is a file with a given name, but not its contents. To get rid of this dependency, we are considering to simply generate a file containing the dirstate of default_images (for example the output of find default_images) and put that in the solver. rsc would use the contents of that file, and would not try to search default_images directly. This would: - reduce dependencies - for example allow to build sw without having a complete default_images around - ease further efforts like split build/better support for full deps Opinions? Best Regards, Bjoern Michaelsen (1) http://wiki.services.openoffice.org/wiki/Build_Environment_Effort -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [extensions-dev] IDL references from the Wiki - via IDL tags
On Wed, 11 Nov 2009 14:17:04 +0100 Juergen Schmidt juergen.schm...@sun.com wrote: this can be seen more as a reminder to make use of the IDL tags, see http://wiki.services.openoffice.org/wiki/Wiki_maintenance/IDLTagExtension for detailed info. And while we at it, please also use: http://wiki.services.openoffice.org/wiki/Special:Interwiki http://wiki.services.openoffice.org/wiki/Template:M http://wiki.services.openoffice.org/wiki/Template:CWS http://wiki.services.openoffice.org/wiki/Template:Bug and follow the guidelines in: http://wiki.services.openoffice.org/wiki/User_Experience/SOP Best Regards, Bjoern Michaelsen -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
On Tue, 27 Oct 2009 13:04:50 +0100 Christian Lohmaier cl...@openoffice.org wrote: Pushing the other ones doesn't do any harm besides wasting bandwidth on a push. Thats not entirely true. This is the way there is harm by adding superficial heads to an outgoing repo: - RelEng expects a cws repo to contain exactly one head on integration. They do not want to have to figure out which of multiple heads should be integrated. This is a reasonable requirement. - Thus all heads on an outgoing repository need to be merged before integration. Since all heads are merged into one and this one head will be integrated, everything on the cws will be integrated in the master. - Thus there is no way to have an scrap branch on an outgoing repo that will not be integrated in the master. The only way to get rid of unwanted experimental branches is to open a new cws, cherrypick branches over to the new cws and then delete the old cws. tl;dr: Do NOT create multiple heads in outgoing repos. [...] real 0m1.551s user 0m0.100s sys 0m1.450s Well, thats all true with any real OS and FS. Unfortunately, on Windows time and space requirements are quite different. ..instead just use hg push -r tip, to only push the head you're actually working on. Or, if unsure, do not create multiple heads (unless temporarily on a local repo when you do the equivalent of a cws rebase, in which case you are merging them immediately). Best Regards, Bjoern Michaelsen -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
On Tue, 27 Oct 2009 14:22:31 +0100 Jens-Heiner Rechtien jens-heiner.recht...@sun.com wrote: Actually, I'm thinking about a hook which will prevent the creation of new heads on the outgoing repositories. Not yet implemented, though. This time, unlike last time, I am against such a hook. ;-) If somebody creates multiple heads on an outgoing repo, no harm was done to the master. This is different than with SVN. However, it has to be clear that such a repo will never be integrated unless all heads are merged. Still, having such repos on outgoing might be of value for experimental minibranches, where one is not certain if they might get integrated one day. When those are on outgoing repos: - They are on backup as long as it is uncertain if they will make it to the master. - They can be easily merged into real cws for integration once they seem fit for it. - They can be simply deleted with the repo if they prove faulty. Nothing of value will be lost. If you want to make absolutely clear that a cws wont be integrated when its repo has multiple heads, I would propose to add another Test to EIS showing this nifty stopsign and scary red boxes, if the cws repo has multiple heads. Best Regards, Bjoern Michaelsen -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
On Tue, 27 Oct 2009 14:25:40 +0100 Jens-Heiner Rechtien jens-heiner.recht...@sun.com wrote: Regarding your idea with reorganizing the pages. I like that :-). Maybe we could just forward the old pages to the new ones (only the OOo and Mercurial one, no need to bother with rest). All pages moved, all wiki internal links updated. Redirects are in place (thats the default when moving). Maybe we can remove the redirect pages in 6 month when this stuff is old. Best Regards, Bjoern -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] OpenOffice.org Wiki Categories
Hi List, I tried to add a bit of structure to to the categories used on the Openoffice.org Wiki. I hope the most important ones are now a direct or indirect subcategory of the MainIndex at: http://wiki.services.openoffice.org/wiki/Category:MainIndex Please check, if your category has found a place in the hierarchy, if not, sort it in. In addition, I tried to sort categories in as at least one direct or indirect subcategory of an OpenOffice.org project. This is to help attributing responsibility for pages. Finally, I am proposing to link to [[:Category:MainIndex]] from the frontpage. Hopefully this will aid to keep the Wiki a bit more structured. Comments? Best Regards, Bjoern Michaelsen -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] OpenOffice.org Wiki Categories
On Mon, 26 Oct 2009 13:38:44 +0100 Juergen Schmidt juergen.schm...@sun.com wrote: it seems to be a good start but probably some more main categories are necessary. But then the question is if we need it at all or if a reworked main page would help to navigate in and through the wiki. Without categories, there will be an ever-growing number of obsolete, outdated and orphaned pages. This is not a problem for navigation from the main page, but it will make the search functionality of the wiki more and more useless. I think a common agreement on how to use categories and sub categories would be more helpful. Like: http://wiki.services.openoffice.org/wiki/User_Experience/SOP/Wiki/Categories http://wiki.services.openoffice.org/wiki/User_Experience/SOP/Wiki/New_Wiki_Pages for starters? Yes, I think every new page should be in at least one category that is a project (or a subcategory of a project). Take a look for example on Tutorials. Clicking on the category shows a lot of tutorials and when you expand the node in the main index you get a sub category Basic:Tutorials. What does it mean, no other tutorials or only a different usage of categories? Looks confusing to me. Yeah, right. But I think ordering the categories is the second step, first we will need to get stuff into at least one category and make each category a direct or indirect subcategory of MainIndex. Then we can really see whats there and consolidate. That being said, I already did some obvious cleanups along the way (like merging the Project and Projects categories). I miss for example the category Conferences and a related entry in the main index. The same for Marketing. Huh? MainIndex - Project - Markting - Conferences seems pretty straightforward to me. That being said those _are_ already listed on the frontpage. Best Regards, Bjoern -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] OpenOffice.org Wiki Categories
On Mon, 26 Oct 2009 14:59:28 +0100 Juergen Schmidt juergen.schm...@sun.com wrote: bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: ah i see, but Marketing is so important from my point of view that i wouldn't have searched under Project. Well but that is my personal problem with all the sub projects. I dont think importance should play a role on the Index Page. Thats what the main page is for. The index should: - offer a structure to search for things in a hierarchy - allow to attribute reponsibility for content in the wiki For me it's still more natural to see the OpneOffice.org project with several main entry points independent of any sub project. Related to a MainIndex i would expect entry points like Development, Documentation, Marketing ... Development, Documentation and NLC are right on the toplevel because they contain so many subcategories themselves (15). Wiki is there because it contains important meta-information. However, Development is problematic in itself, as people use different definitions. Some use it for stuff doing development on top of OOo as a blackbox-framework via the API (Extensions, Basic macros etc.), while others use it for development on OOos internals itself. In the end this dilutes the category and its use. Good categories would seperate: - end users (category:enduser) - Developers using OOo as a blackbox platform (extensions, macros, etc.) (category:ApiDevelopment ?) - OOo internal development (category:CoreDevelopment ?) But its still a long way to get there. Best Regards, Bjoern -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Dropping tcsh support for Mac (all?) / changing configure's default
Christian Lohmaier cloph at openoffice.org writes: Too bad that you wrote IEEE 1003.1, since if it was 1003.2, then one could set POSIXLY_CORRECT variable to switch bash to posix mode and test with that. Or is there no difference wrt shell behaviour? I am not a posix standards expert at all, but AFAIK 1003.2 is part of the newest revision of 1003.1 (as confusing as that might sound). see http://www.opengroup.org/austin/papers/posix_faq.html Question 10. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [tools-dev] Line-endings in source files
Jan Holesovsky kendy at suse.cz writes: I can only emphasize how important this is. Bjoern kindly offered to do a Python version of a pre-commit hook once; it was more complex, but can we at least try the CRLF check? Bjoern, would you be willing to provide that, if Heiner agrees to use it? I am currently on vacation and will likely be offline (and off infrastructure) for some time. I know that it is sneaky and cowardly to try to use that as an excuse, but I will take a look when I return (if its still relevant then). IIRC Heiner has implemented a commit hook for commits on tags - so it is likely that it is much easier to just extend that hook than writing an additional one. However, since our months left with SVN as our main SCM are hopefully single-digit numbers I wonder if it is still worth the effort. Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Important Process for Mercurial Users
Jens-Heiner Rechtien Jens-Heiner.Rechtien at Sun.COM writes: I'll keep that in mind. Some great suggestions here, I'll have a look at them! Well, if we have postcommit hooks on the outgoing repositories wouldnt it be even simpler to just check the milestone that is set in the source code (in solenv/inc/minor.mk) instead of using tags or anything like that? I guess it would actually also be much more robust. Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Mercurial-Implementation: OOo domain developer public keys
Martin Hollmichel Martin.Hollmichel at Sun.COM writes: Do you think - with the switch to Mercurial - would it be possible to stop using the 'CWS' and 'MWS' terminology, and instead switch to the commonly used 'feature branch' and 'release branch' terms? +1, +1 too. However, that might require to getting out the soldering iron as this is pretty much hardwired in some devs brains. It doesnt help that CWS is actually a rather short and convenient term - it takes time to teach old dogs new tricks ;-) Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Unable to compile on Ubuntu (Jaunty)
L Duperval lduperval at yahoo.com writes: I am trying to compile )) 3.1 from the source code on an x64 Ubuntu Jaunty machine. When I compile, the packaging fails (I think). It seems to be trying to package for .deb, even though I set FORCE2ARCHIVE, set INSTALLDIRRECTORY and set PACKAGE to installed (without the quotes) Woha! Thats a bit too much! Either PACKAGE=installed _OR_ FORCE2ARCHIVE. ... Package format: archive Its trying to build a tarball (the .deb stuff later is just the name of the makefile-target). ERROR: The following files could not be found: ERROR: File not found: dict-af.oxt ... Here is your problem. These files seem to be missing in your solver. Try rebuilding and redelivering module dictionaries. cd dictionaries build deliver ERROR: Saved logfile: .. instsetoo_native/unxlngx6.pro/OpenOffice/archive/\ logging/en-US/log_OOO310_en-US.log That one should be investigated too. Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Unable to compile on Ubuntu (Jaunty)
L Duperval lduperval at yahoo.com writes: ** ERROR: ERROR: unopkg add --shared \ --verbose ../share/extension/install/dict-fr.oxt -env:UserInstallation=file:///home/laurent/devel/OOO310_m11/instsetoo_native\ /unxlngx6.pro/OpenOffice/archive/uno/en-US 21 | failed! in function: register_extensions ** see http://qa.openoffice.org/issues/show_bug.cgi?id=103269 Workaround: cp dict-de.oxt over dict-fr.oxt in solver/300/unxlngx6.pro/pck or build without french dicts (for example: ./configure --with-dict=ENGB) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Duplicated header contents in svx
Kohei Yoshida kyoshida at novell.com writes: The bad news is that this file is not the only file with duplicated content. In the same directory, I've found several other headers with the same duplication problem. AccessibleStaticTextBase.hxx and acorrcfg.hxx are also affected, quite possibly others too. The duplicate you posted was introduced with CWS changefileheader. Maybe someone should take a look at the files changed by that cws? The good news is that this does not break anything thanks to those header guards, but I guess we should still fix this... True. Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Duplicated header contents in svx
Christian Lohmaier cloph at openoffice.org writes: No, not true. it was added with os128 Oh, ups - Im too dump to use opengroks history differ. True, but of course for the correct cws. Ok, I will have a look next week (as os is on vacation). I will try to have a look too at the cws commits to see wtf happened there. Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Error building on cygwin: Missing nsIAbLDAPAttributeMap.h
T. J. Frazier tjfrazier at cfl.rr.com writes: My thought is to put the table itself at the top (with a brief introduction), and let all the explanations follow, with no other external links. From our point of view, it makes maintenance easier and more reliable. For the users, the table is what they're going to want to refer to, probably over and over; having it at the top makes it easy to find. If we tune the section headers so that they have the same names as the table entries, then the users can use the TOC to go straight to some individual explanation they need to look up. Or, on-page links to the sections would be easy enough. Yeah, maybe that would be better. Originally, I intended not having that stuff on the top because a big table might scare away newcomers. All this is a fairly major reshuffle. If you have no major objections, I'll do it, but your critical review (of the plan, and the result) is very important: I've never built OO.o at all. Go ahead, Ill have a look later (just make sure that you dont drop any footnotes ;-) ). Maybe you could also update the linux stuff to the same format. BTW, I too rarely do manual community builds on windows myself (Im working on linux and use buildbots whereever I can). Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: What is a SLOT and What is a WHICH?
Zhu Lihua zhulihua at redoffice.com writes:
Hi all,
I read the following code in OOo source code(itempool.hxx):
#define SFX_WHICH_MAX 4999
static intIsWhich(USHORT nId) {
return nId nId = SFX_WHICH_MAX; }
static intIsSlot(USHORT nId) {
return nId nId SFX_WHICH_MAX; }
I think: if nId 4999, it's a Slot. if nId = 4999 and nId !=0 , it's a
Which.
What are the terms slot and which mean?
Thank you!
A WhichId is the id by which items are stored in SfxItemSets and SfxItemPools.
You cannot have two items with the same WhichId in on SfxItemSet. However,
there are multiple uses for WhichIds: SfxSlotIds are only one and they are
required to start at 5000. In writer for example HintIds can also be used
as WhichIds. To make sure those do not collide, HintIds must be 5000.
SlotIds are used in the Sfx2 framework. see:
http://wiki.services.openoffice.org/wiki/Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2
SlotIds are at least unique per Shell (*).
There are some fine differences in the way SfxItemSets/SfxPropertySets handle
ids 5000 and ids =5000. For example, the Changed(..)-Callback in SfxItemSet
only gets called for WhichIds 5000. For more details, Im afraid you will have
to dig into the code.
Have Fun,
Bjoern
(*) I guess, they might even be unique OOo-wide, but Im not sure about that.
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Error building on cygwin: Missing nsIAbLDAPAttributeMap.h
Stephan Bergmann Stephan.Bergmann at Sun.COM writes: (Put Björn on cc, who might like to clarify in the guide which zips to download for which source revision.) Done: Put the link for current milestones in the Building Guide, and added the older links on the page about building older releases/milestones. Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Error building on cygwin: Missing nsIAbLDAPAttributeMap.h
T. J. Frazier tjfrazier at cfl.rr.com writes: Did you miss the second link, down in the adding required files to the build tree section? Yes. Fixed now. I'd have fixed this myself, but do we want a better solution, with the link in only one place? I would prefer a link in one place too, but the links are sensible in both locations, I think (I would like to have the needed downloads at the top of the page), but I would also want those to identify what goes where. If you have a good solution for this, go ahead (maybe one could just name the requirements at the top and refer to the table below for source and destination locations?). Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Contributing
Jeff Beauman jebeauman at charter.net writes: I've been writing mid-range code since 1983. For the past two years I've taken classes in C++, SQL, Game Programming, Assembler, and Visual Basic. In fact, I got my AAS this spring. I'm not sure how much help I can be to OO but I'm willing to try. How do I start? Jeff Beauman Hi Jeff, the first step is to do an OpenOffice.org build. We recently updated the documentation for that: http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide If you have any issues with the docs, please drop us a note. After successfully building OOo, find an area of interest and dig into the code (OOo is huge). Find some open issue in bugzie: http://qa.openoffice.org/issues/ and fix it. In the beginning you might want to just submit a patch: http://wiki.services.openoffice.org/wiki/Contributing_Patches Later, you might want to use your own child workspace aka cws (basically your own feature branch). We will help you along, when you are at that point. ;-) see also: http://contributing.openoffice.org/programming.html Have Fun, Bjoern P.S.: Also, there is the Dev Guide: http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/OpenOffice.org_Developers_Guide Explaining the whole OOo framework and how stuff is intended to be used. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: build into installation
Terrence Miller terrencem at sbcglobal.net writes: I just completed my first build (8 hours on a Toshiba laptop) ( configure args and packages added documented in attached script). I followed the directions from the wiki page and added: export LOCALINSTALLDIR=/home/tcm/dest/second_try mkdir -p $LOCALINSTALLDIR export PKGFORMAT=installed between the calls to bootstrap and configure in order to generate a ready-to-run installation but ended up with a directory full of Debian packages. Any suggestions? Oh yeah, the docs should be more clear on that one: PKGFORMAT gets set to a default value (deb) when you source the LinuxEnv*.sh file. So you have to set the var either after sourceing that file or change the setting right in the file. You can do this: cd $SRCROOT source LinuxEnv*.sh export LOCALINSTALLDIR=/home/tcm/dest/second_try mkdir -p $LOCALINSTALLDIR export PKGFORMAT=installed cd $SRCROOT/instsetoo_native build If you have not deleted your solver, an installation will be prepared without the need to recompile anything. Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Build Comments
Thorsten Behrens thb at openoffice.org writes: all distros I know of are using the non-gpc clipper since ages, I'm not aware of any regressions there. Also, if my memory does not fail me, Hamburg switched to non-gpc for 3.0, at least I don't find any traces of WITH_GPC in solenv anymore. Ok, I will remove the references from to gpc from the Building Guide for current releases. However, the directory external/gpc needs to be removed and configure needs to get rid of related options. Is there a bug for this already or do I need to open a new one? Best Regards, Bjoern Michaelsen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Consolidating build instructions for the community
Per Eriksson pereriksson at openoffice.org writes: I agree that striping OpenOffice.org and moving to documentation is a good idea. Bjoern feel free to do it. done. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Consolidating build instructions for the community
T. J. Frazier tjfrazier at cfl.rr.com writes: done. Okay, guys, TOC template time, or transclusion time, to get rid of all that redirect trash at the top of every referenced page. Ugh, true. The TOC has to be changed on every BG page. Is anybody else volunteering, or shall I do something (transclusion or template, not sure which)? Please go ahead, I am not really that skilled with wiki stuff. From what I read on transclusion when you mentioned it, it seems to be the right tool for the job. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Build Comments
Terrence Miller terrencem at sbcglobal.net writes: I am about half way through my first build Hi Terrence, thank you for taking the time to report back. and have already run into things which could lead to unstable Linux builds: My experience has convinced me that any source information needed to do a build should be in a source file and stored locally. Well, for some stuff, that is not possible for legal reasons (licenses etc.). Examples of information that should be in a source files are: - A list of all the packages which need to be installed in order for the build to succeed. OpenOffice can be build almost selfcontained with almost no external dependencies. The deps start to get interesting when you use the --with-system- switch and use distro-provided packages. However, when reproducable builds are the aim (as are for our RelEngs), you wouldnt be using anything external, but use the library versions from the OOo repo. So the information is in the source files: The reference version of a library is the one found in the OOo repo. (better yet a script which will put a system in the desired state.) - the options specified to configure Thats a package maintainer task (as package maintainers might want to compile against patched libs, or enable/disable features). Also having any source files copied into external is (in my opinion) a problem. For example, the URL for gpc.[ch] could go dead overnight with no warning. Right, this is why this dep will be completely removed for 3.2. If OOo wants to be able to reproduce builds, we will need to have a local snapshot of any package listed as a build requirement. Where possible those are already in the OOo repo. Thanks for your comments and enjoy hacking OOo! Best Regards, Bjoern Michaelsen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Build Comments
Terrence Miller terrencem at sbcglobal.net writes: In current scheme you end up running configure once for each missing package (since it stops on first error). Sometimes the error message is useful but not always. I understand the problem, but unfortunately maintaining an up-to-date complete list of deps is a lot of work (since those deps are also constantly moving). What we might try to seduce RelEng to is to make configure output all deps it is looking for, but I dont know if that can be easily (automatically) done. At least on Ubuntu there is a way to map from the name of a missing file to the name of the package supplying that file. Well, there is some kind of reference all the time - if you are not a package maintainer you can look at the source package of your distro. If you are a package maintainer, you can have a look at the source packages of other distros. A release is built with some fixed set of options. The documentation has an example for Ubuntu 9.04 but gives no clue what to do in any other situations. The wiki page is probably the wrong place for multiple examples Yep, those infos are kept in the source packages of the distro repo. Why would you want to do that in the first place? A year later so much stuff has changed in the sources - why would you want to build such an old version then? A critical bug in an old release has been reported by an important user and the latest release contains a UI change the user is unwilling to adopt. All relevant distros kept their source packages/ebuilds in a repository. Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Consolidating build instructions for the community
Per Eriksson pereriksson at openoffice.org writes: Christian had a good point regarding simple instructions previously. As you mentioned, the instructions are similar. There are big possibilities that we want to add platform-specific notes, comments, references to other documentation (e.g. the Solaris documentation) that is platform-specific later, letting the content remain today would give us most options available, which I think is a strong benefit. I actually think that is misguided, because building instructions are changing fast. I have brought Windows and Linux instructions pretty much up to date and in sync. However, I also had to: - copy a lot of useful (platform independent) information from one article to another because it was missing there. - delete quite some outdated/misleading information that was only removed/updated for one platform. If nobody actively supervises the docs and keeps them in sync, then in 6 month a new dev will need to read the docs of _all_ platforms, if he does not want to miss something, because lots of platform independent information was only added/updated/removed on the article of one platform. Also the logical structure of the articles will divert and thus make it harder for a dev to transplant his knowledge from one platform to another (simply because he wouldnt be able to easily navigate the other articles because of the different structure). Having one article per platform would be a nifty idea - if we wrote a book and the build enviroment wouldnt be changing. But trust me: After reading the mess that were our build docs (scattered over way too many different places), I can assure you: Putting platform independent infos redundant in articles for each platform is a Bad Thing(tm). Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Consolidating build instructions for the community
Per Eriksson pereriksson at openoffice.org writes: Here is how far I've come so far. Several pages' content have now been moved to these 7 pages: http://wiki.services.openoffice.org/wiki/Development/OpenOffice.org_Building_Guide Hi Per, I did quite some cleanup in Building on Linux. However, I noted that there are large parts in it that are platform-independant. I am suggesting to add a section Building before the Building on ... sections and consolidating all platform-independant stuff there. Of Building on Linux will not be much left (dito for Solaris), because the software/hardware requirements (and special stuff like debugging) are pretty much the only things that are platform-specific. Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Consolidating build instructions for the community
Christian Lohmaier cloph at openoffice.org writes: My problem is that everyone is eager to start new projects, new efforts instead of improviing what is there already. Cleaning up the docs _is_ improving what is already there. My problem is that if you really feel the need of simplifying the build, then don't do it by adding instructions, but by actually making the build itself simpler. Is a different scope and there are different skillsets needed for both tasks. And both efforts can produce better results. No. I did compile OOo myself for the first time in the past as well. At that time, I just did read the instructions and off it went. I did look for info. I didn't assume I know already. Well, I you look at the current wikipages, it reads like its written by an ADHS-impaired kid: Lots of You might want to ..., You might need to ... etc. with workarounds for problems that are likely long gone. Quoting the Zen of Python: There should be one-- and preferably only one --obvious way to do it. The docs currently provide too many options without noting the one that is the: - most useful - most robust - best documented, updated and supported If configure prints get file from URL or use mingw and people still complain about not being able to tell where to get file, that sepaks for itself. For example, in that particular case I am still wondering, why the URL that configure barfs out isnt a direct one (that is wget-able), but one to an directory where one finds the link to the real unowinreg.dll. Thats just unneeded hassle. Probably that's another part of the problem I have. This makes it sound like there wouldn't be any documenation for new builders at all. That's just not the case. Actually, outdated documentation is much worse than no documentation. Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Interested in helping with development
Terrence Miller terrencem at sbcglobal.net writes: To avoid going crazy with nothing to do I would like to become involved with Open Office. Low level C++ issues such as exception handling is the area I know the most about. I have access to systems running Windows XP and Ubuntu Linux. Hi Terence, Well, for starters just try to build the product: http://wiki.services.openoffice.org/wiki/Development/OpenOffice.org_Building_Guide Feel free to report any problems you ran into when trying to compile OOo. I would recommend to use Linux as development platform if you are free to choose. When you are done with a build, you might help us by fixing a bug of your choice ;-). For further discussion on what can be done and how to get started I guess its best to join the IRC-channel #dev.openoffice.org on freenode. Have Fun, Bjoern Michaelsen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Consolidating build instructions for the community
Per Eriksson pereriksson at openoffice.org writes: Thanks for all the kind words. I have created the guide here: http://wiki.services.openoffice.org/wiki/Development/OpenOffice.org_Building_Guide And these are the page created so far: OpenOffice.org_Building_Guide OpenOffice.org_Building_Guide/Introduction OpenOffice.org_Building_Guide/Getting the source OpenOffice.org_Building_Guide/Basic Concepts ... Hi Per, great stuff, but can you make the source wiki pages from which the info in the Building Guide is collected #REDIRECT to the development guide? That would help weed out old and rotting duplicate content. I did that already with the Getting the source page (and also updated/fixed a bit in it). We should viciously remove all those distributed tidbit-pages (after their info is in the build guide) as those do, among other things, mess up search results. Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Consolidating developer documentation
Hi List, While checking, sorting and refactoring stuff for the new building guide, I also ventured into our CVS/SCM/CWS docs. I merged/renamed some stuff, created redirects and tagged some stuff with categories (mostly development, SVN, SCM, CWS). However, there are quite some stuff that is really mixed up, for example infos about SCM-tooling, EIS-tooling and basic QA-workflow are distributed and mixed all over these pages (and some more): http://wiki.services.openoffice.org/wiki/CWS http://wiki.services.openoffice.org/wiki/ChildWorkSpace http://wiki.services.openoffice.org/wiki/EIS I think it would make sense to clearly separate: * cws, the command line tool * cws workflow for developers (including how to use EIS) ^- this one should be further reading in the Building Guide * cws workflow for QAs (inlcuding how to use EIS) (and getting rid of outdated/wrong stuff by the way) Also we need to clean up category:CWS: http://wiki.services.openoffice.org/wiki/Category:CWS Currently, it contains: * SCM tools usage (ok) * QA Policies (ok) * various QA stuff (Gatekeeper, RedTinderboxStatusInEIS) (meh) * QA Status Pages of some cws's (huh?) Im proposing to get rid of the CWS QA states at least (or move them to a new Category:CWSQAStatus). I think these pages (which _should_ be the first thing a contributor reads after having his build enviroment set) should be worth the effort. Comments? Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Consolidating build instructions for the community
Per Eriksson pereriksson at openoffice.org writes: If you think this is a good idea, I will start a new small effort for this in the wiki. I think it is a very good idea. When restructuring the information about building, we should take care to distill the happy path (http://en.wikipedia.org/wiki/Happy_path) from all the special cases (Tips and Tricks etc.) and get rid of obsolete stuff (for example: cvs). Please tell if you need any help, I will try to support the effort. Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: oooimprovement thing and BUILD_SPECIAL
Caolán McNamara caolanm at redhat.com writes: 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 ? (although we just chatted about this on IRC, here is the synopsis for the mailing list archive) The only difference between a build with oooimprovement and a build without it is that the User Feedback Program (part of Project Renaissance) is enabled with oooimprovement. http://wiki.services.openoffice.org/wiki/User_Experience/OpenOffice.org_User_Feedback_Program Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Moving files in a Subversion CWS
Jens-Heiner Rechtien wrote: Hi, I wouldn't call for a complete ban but it looks like one has to be extra careful. Restructuring should be done in CWS which lives only a very short time. Best, say, opened on one milestone and integrated in the next (as first CWS) this would minimize the potential for data loss. As first CWS? Wouldnt that doom any changes from other CWS on the moved files because the file is already deleted when they are itegrated. *Confused* I thought _last_ CWS would be the safest ... Still data loss is possible even in this scenario, which IMHO is very scary. I would feel much more comfortable, if a naked move wouldnt be possible. As an (ugly, very ugly) workaround for now, we might need a command in the cws tool that registers the moved files by their old name (the name it is known as on the master) somewhere. This could be either in a svn property (on trunk??) or in a administrative file somewhere. It should at least be noted, if changes to a file are wandering to /dev/null. Have Fun, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: Moving files in a Subversion CWS
Frank Schönheit - Sun Microsystems Germany wrote: Perhaps a postprocess hook which sends mails to EIS, keeping track of moved files, and issueing warnings upon integration when some change is about to be lost? I fear this is not possible in post-commit, as the info that something was a move isnt available anymore, because it will show up as a delete and an addition in the commit when you analyse it with svnlook. ugh. Best Regards, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: Writer Code Conventions / Cpp Coding Standards
On 10/20/08 15:05, Thorsten Behrens wrote: I see. But this surely doesn't apply to all-new files, no? No (other than that you cannot checkout a file that exists in a working copy using a different case, but that is to be expected with caseinsensitive filesystems). (is there an svn bug filed for this already?) I dont know, maybe it is even fixed in current releases. I just remember doing a svn mv on *nix once and as it gets translated to a deletion and an addition with history, the addition might fail because the old file is still there. Ok, then fine with that - except that I'd veto the one-line if-statement (prevents setting a breakpoint there for various frontends), I extended the description, one liners arent strictly forbidden, but strongly adviced against. and the non-alignment of statements (proper editors do that en passant, and it's quicker to parse for the eye). [Now you see where it leads, when trying to agree on formatting ;)] We could fight a lng fight about that one(*), but shouldnt (or we should when we are sitting together some evening and having a beer). Lets just keep it with we agree to disagree there. The writer team is ok with the current proposal, if you want to propose the code conventions to other team, just leave out those you dont like. Please feel free to add recommandarions about SAL_NO_VTABLE, SAL_DLLPUBLIC_EXPORT, SAL_DLLPUBLIC_IMPORT and SAL_DLLPRIVATE. Will do - seeing that you're working on it, can you ping me for a handover in private? Adding stuff shouldnt be a problem, so just go for it. However, existing conventions have already meet the consensus of the writer team and thus should be kept for now. Have Fun, Björn (*) I would argue that alignment of statements is essential for deeply nested languages like lisp and ocaml, but actually hurts with C/C++ or Java. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Subversion precommit hook
Hi list,
since we now have subversion, we might as well use the new features it
provides. I wrote a precommit hook on the weekend that does some
precommit sanity checks:
- It rejects commits changing files in a cws and outside of it (thus
hopefully preventing some accidental commits to a master
- It checks all *.{cxx|c|hxx|h} files for correct indentation (no tab
indentation on added/changed lines)
- Adding a new module has to be properly announced in the commit message
- Adding a new toplevel dir in a module has to be properly announced in
the commit message (this hopefully prevents accidental commit of
output trees)
- Never allows changes/deleting of tagged versions
I crucified myself to write the hook in perl because I thought it to be
the preferred language for releng stuff (I would have preferred python
myself).
All checks can be disabled with adding special strings to the commit
message.
Im looking forward to comments, ideas and additions. Is it a good idea
to use such a precommit hook? Whats relengs position on this?
Have Fun,
Björn
#!/usr/bin/perl
use strict;
use warnings;
use Getopt::Long;
#global constants
my $SVNLOOK_CMD=svnlook;
#global vars for checks
my $log_message = ; # log message of transaction
my @added_files = (); # files added by the transaction
my @deleted_files = (); # files deleted by the transaction
my @updated_files = (); # files updated by the transaction
my @all_files = (); # all files touched by the transaction
my @all_dir = (); # all dirs touched by the transaction
my $error_message = ; # error message of the precommit hook.
# if no check fails, the string is empty
# If an error occurs append the message
my @checks = (); # add checks to this array
sub check_cws_isolation
{
return if($main::log_message =~ /IGNORE CWS ISOLATION/);
my %touched_cws_hash = ();
foreach my $cws (@main::all_dirs)
{
if($cws =~ s/^cws\/([^\/]+)\/.*$/$1/)
{
$touched_cws_hash{$cws} = 1;
}
elsif(!($cws =~ /^cws\/$/))
{
$touched_cws_hash{Non-CWS Location} = 1;
}
}
my @touched_cws = keys(%touched_cws_hash);
if($main::debug)
{
print DEBUG: touched CWS: @touched_cws\n;
}
if(@touched_cws 1)
{
$main::error_message .= cws isolation: Commit touches multiple cws. Do
a seperate commit for each cws.\n;
$main::error_message .= cws isolation: Touched cws are:
@touched_cws.\n;
$main::error_message .= cws isolation: Add 'IGNORE CWS ISOLATION' to
log message to force the commit.\n;
}
}
push(@checks, \check_cws_isolation);
# helper: check if there is a tab-indent in new line
sub check_indentation_from_filediff
{
my @filediff = @_;
return if(@filediff == 0);
my $filename = $filediff[0];
my $nonconforming = ;
$filename =~ s/[^:]+: (.*)$/$1/;
return if(!($filename =~ /^.*\.(cxx|hxx|c|h)$/));
foreach my $line (@filediff)
{
$nonconforming = true if($line =~ /^\+\ *\t/);
}
if($nonconforming)
{
$main::error_message .= indentation: Commit contains new/changed lines
with nonconforming indentation.\n;
$main::error_message .= indentation: Offending file is: $filename.\n;
$main::error_message .= indentation: Add 'NONCONFORMING INDENTATION'
to log message to force the commit.\n;
}
}
sub check_indentation
{
return if($main::log_message =~ /NONCONFORMING INDENTATION/);
my @diff_lines = split(\n, exec_svnlook(diff --no-diff-deleted));
my @one_file_diff = ();
foreach my $line (@diff_lines)
{
if($line =~ /^[A-Za]/)
{
check_indentation_from_filediff(@one_file_diff);
@one_file_diff = ();
}
push(@one_file_diff, $line);
}
check_indentation_from_filediff(@one_file_diff);
}
push(@checks, \check_indentation);
sub check_new_modules_in_cws
{
return if($main::log_message =~ /NEW MODULE/);
foreach my $new_module (@added_files)
{
if($new_module =~ s/^cws\/([^\/]+)\/([^\/]+)\/$/$2 in $3/)
{
$main::error_message .= new module in cws: Commit contains a new
module.\n;
$main::error_message .= new module in cws: new module is:
$new_module.\n;
$main::error_message .= new module in cws: Add 'NEW MODULE' to log
message to force the commit.\n;
}
}
}
push(@checks, \check_new_modules_in_cws);
sub check_new_toplevel_in_module
{
return if($main::log_message =~ /NEW TOPLEVEL DIR/);
foreach my $new_topdir (@added_files)
{
if($new_topdir =~ s/^cws\/([^\/]+)\/([^\/]+)\/([^\/]+)\/$/$3 in
module $2 in cws $1/)
{
$main::error_message .= new toplevel dir in module: Commit
containing a new toplevel dir in a module.\n;
$main::error_message .= new toplevel dir in module: new toplevel
dir is: $new_topdir.\n;
$main::error_message .= new toplevel dir in module: Add 'NEW
Re: [dev] Subversion precommit hook
On 10/20/08 12:56, Frank Schönheit - Sun Microsystems Germany wrote: ... modules ... Not sure this is needed. AFAIK it is (at least in CVS times it was) necessary to do other things for adding a new module (announcement to releng etc.), so just preventing the commit doesn't really solve a problem, IMO. ... toplevel dirs ... Not sure this is worth it. I still think ignore lists are the best way to prevent accidental committing of output trees, and for all other dirs, we should not force us to a special commit message without a need. Subversion does not care about modules, however the build system might. Restricting toplevel dirs are probably an superfluous hassle - it was just something that was easily implemented after having code watching for certain dirs. I added the toplevel dir stuff, because you can still commit an svn:ignored directory. However, Im not vicious about that toplevel stuff. Given that pre- and postcommit hooks are basically working the same, using this precommit hooks as a base to create a postcommit hook should be easy. That hook should automagically svn:ignore output dirs when a new module is created in a cws. I think that would better than a cronjob svn:ignoreing all files as: - output trees are svn:ignored right after the module is created and even in the cws - you only need to manage the platforms in the postcommit hook, no need to track every platform/module combination. - Never allows changes/deleting of tagged versions preventing changes sounds good, preventing deletion of tags - not sure. At least in CVS times, tags became a pain in the neck over time (because there were so many), but this probably doesn't apply to SVN. Its less of an issue with svn and remember this check can be disabled by a special commit message (containing MODIFY TAGS). The svn-client would barf up that info too when rejecting a commit. Have Fun, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Subversion precommit hook
On 10/20/08 12:51, Rene Engelhard wrote: How should that be possible when you svn switch a complete tree to a cws (which you should do)? There's no need for any checks at all, if everybody does what he should do ;-). There's no modules anymore but one big tree. That check imho is moot. Indeed. However, the build system still sees a difference between a dir and a module. ... toplevel dirs in modules ... Err? Why should that be disallowed? And how does that help? For adding output trees you'd need a svn add on that anyway, so... If people do that you can't help them anyway... Currently we have the output trees svn:ignored. svn add * would still happily add the output trees. I would bet this will bite someone sometime. IIRC someone commited a output tree to the CVS once. However, I dont think it is essential to have such a check in the precommit hook - its merely a proposal. Have Fun, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Subversion precommit hook
On 10/20/08 15:08, Frank Schönheit - Sun Microsystems Germany wrote: See issue 95199 for my currently prepared (and already implemented) solution, though a post-commit hook also sounds interesting. I just tried to add an svn:ignored dir. That works. If someone does a svn diff in a module, and sees: ? source/somenewfile.cxx ? source/somenewfile.hxx he might be tempted to do a 'svn add *; svn ci -m my message' and goes to grap a coffee. When he returns he has happily commited the output trees. That seems kinda dangerous to me. If we svn:ignore output trees, we should also prevent them from being commited (if we have a list of platforms that are svn:ignored, we could also specifically look for those in the precommit hook). BTW this is just as dangerous when having the output trees in global ignore in the config. Have Fun, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Subversion precommit hook
On 10/20/08 17:39, Philipp Lohmann wrote: Hi, Jens-Heiner Rechtien wrote: I somehow don't like tying SCM functionality to commit messages, but that's may be just me. And should we enforce policy (like tabs vs spaces etc) via the SCM tool? is there another point where we could actually enforce policy ? Enforce as in preemptive, not cooperating ? It would have the advantage that people cannot simply forget this. OTOH code formatting has the potential to create a holy war about nothing (namely whitespace). Well, there is a clearcut requirement in the OOo coding style. And whitespace is not nothing, as it is really reducing productivity on merges/rebases. Personally I'd prefer this to be not a check, but an automatic on the fly reformat - but I assume that would occasionally break a file, if the input deviates too much (or in an unexpected way) from the expected format. The only alternative point where this could be enforced is on the master: After all cws are integrated, all lines that were added/updated all reformatted. This would ensure no nonconforming new code will be added, without creating huge diffs that every cws would have to cope with on merge/rebase. Have Fun, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Subversion precommit hook
On 10/20/08 17:10, Jens-Heiner Rechtien wrote: there was no need for crucifying yourself, server side we are python only. Actually we have no perl bindings installed. If I only had known that before. I like and know Python a lot better. I think we need to be a bit carefull with pre-commit hooks. Other than post-commit hooks they do influence the user experience of SVN, so they have to be fast. Well, we've got a very fast server so probably this is not really a problem. I would guess the scripts as of now are not really a performance issue - they only work on the diffs of a commit not on whole files/directory trees as the commit itself has to. Also, I would suggest to add features to the hook bit by bit and not all at once. Have Fun, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SVN-ignored files
On 10/16/08 15:41, Jens-Heiner Rechtien wrote: [...] There is another reason to use svn:ignore set in the repo: There is no way to check if all of us lazy devs really set the stuff in our local svn config. Having svn:ignore on the output tree dirs should make it extra hard for one lazy/tired dev to do an accidental commit containing an output tree. Have Fun, Bjoern P.S.: If a dev still manages to try this, there are only two things that might stop him: - Threats by releng ;-) - a precommit hook - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SVN-ignored files
On 10/16/08 11:00, Malte Timmermann wrote: In short: Can we please add the platform-dependent output tree names as svn:ignore property to all modules? +1 +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] SVN Hooks for formatting (was: Re: [dev] VCS Keywords in License Headers)
On 10/06/08 09:57, Caolán McNamara wrote: 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 +1 I would really appreciate such a hook, I just didnt dare to propose this yet. Have Fun, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
