Hi,
wangxiang schrieb:
hello, fedora12 "yum install openoffice" in my computer no problem
But when i build the Ooo with the latest hg version
i use the "rpm -iv openoffice.org-*rpm" in the folder "instsetoo_native/
unxlngi6.pro/OpenOffice/rpm/install/en-US"
then i run the "/opt/openoffice.
I am trying to build the source code for Open Office on a Windows XP
computer, because I want to look at the code before I apply for one of the
summer internships. I have installed Cygwin and the five modules listed at
http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Buil
hello, fedora12 "yum install openoffice" in my computer no problem
But when i build the Ooo with the latest hg version
i use the "rpm -iv openoffice.org-*rpm" in the folder "instsetoo_native/
unxlngi6.pro/OpenOffice/rpm/install/en-US"
then i run the "/opt/openoffice.org3/prgrams/swriter", it
On 06/15/2010 02:55 AM, Mathias Bauer wrote:
On 14.06.2010 12:01, Caolán McNamara wrote:
A code replacement like this creates the question what shall be the goal:
- reduce memory footprint
- improve performance
- remove code duplication
- improve code quality
My primary interest is in code
Am Tue, 15 Jun 2010 09:04:45 +0200
schrieb Mathias Bauer :
> So this is code broken (the code in the ItemSet, not yours).
I would argue that both code is broken, because as is the ItemSet has
no well-defined contract to design against. Of course, Malte is no more
guilty than anybody else as the on
Am Mon, 14 Jun 2010 14:13:36 -0400
schrieb Bill Hoffman :
> OK, so you depend on gmake features.
Indeed. Some of the recent gmake features are really nifty and make it
quite powerful.
> This might be an interesting thing to try with CMake some day. To
> generate a makefile that does not have recu
On 2010-06-15 10:44, Bjoern Michaelsen wrote:
Am Tue, 15 Jun 2010 09:18:45 +0200
schrieb Jan Holst Jensen:
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;
On 14.06.2010 17:49, Malte Timmermann wrote:
Björn Michaelsen wrote, On 06/14/10 16:09:
Am Mon, 14 Jun 2010 15:11:57 +0200
schrieb Malte Timmermann:
Hi Bjoern,
Björn Michaelsen wrote, On 06/14/10 13:34:
Hi all,
while testing the new SfxItemSets in cws new_itemsets I came across
a few inte
On 14.06.2010 12:01, Caolán McNamara wrote:
On Mon, 2010-06-14 at 11:22 +0200, Michael Stahl wrote:
the SvArrays should be replaced by appropriate STL types (mostly vector, i
guess, but probably in some cases stacks or deques or something else).
deques I think was the best option in general th
Am Tue, 15 Jun 2010 09:18:45 +0200
schrieb Jan Holst Jensen :
> 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)
> >
On 06/15/10 09:06, Bartosz wrote:
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-
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 = aEnt
> 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 poss
13 matches
Mail list logo
