Caolan McNamara

latest DEV300_m43 callcatcher report, +83 unused methods, 55 of which are in the new formula UI library

DEV300_m42 callcatcher results are available. Back up to over 1000 unused methods. sd contains a fifth of all unused methods. i18npool has picked up two new unused destructors, seeing as the constructors are used, there’s probably a leak in there with missing deletes against news. On the bright side, unoxml and sax are now unused method free.

callcatcher DEV300_m40 and in rapid succession, DEV300_m41 results.

sdext stripped of the majority of unused methods, so we’re now down under 900. Biggest win remains sd with 195 methods.

since rene’s work is in place, now in DEV300_m40+ OOo can be built with a simple
./configure
make

DEV300_m39 callcatcher report. Couple of modules go down, a couple go up. Balances out to retain 927 unused methods. The top three offenders remain sd, writerfilter and sc.

Note that if a method declared as pure virtual in class X then if an implementation of that method in class X is provided then it *does not* get called through the vtable, i.e. the body of that method is effectively a non-virtual method, to get called it has to be explicitly called somehow.

So that means that callcatcher is correct if it reports that a pure virtual method is unused. Virtual methods are ignored, but implementations of base-class pure virtuals are a different kettle of fish and can themselves be treated as non-virtuals.

class foo
{
public:
virtual void bar() = 0;
};

//Can only get called by an explicit call of foo::bar() on some concrete subclass of abstract superclass foo
void foo::bar()
{
//something
}

The DEV300_m38 callcatcher results, now with added inline deltas niftyness to show which are the new unused methods since the last run. Overall increase of +5 methods since m37.

So now what am I supposed to do

Back up to 927 unused methods in m36 vs 922 in m35


if ( nSlotId != SID_OBJECT_SELECT &&
(/* bTempRotation && */ nMarkCount==0) ||
( mpView->GetDragMode() == SDRDRAG_CROOK &&
!mpView->IsCrookAllowed( mpView->IsCrookNoContortion() ) ) ||
( mpView->GetDragMode() == SDRDRAG_SHEAR &&
!mpView->IsShearAllowed() && !mpView->IsDistortAllowed() ) ||
( nSlotId==SID_CONVERT_TO_3D_LATHE && pSingleObj &&
(pSingleObj->GetObjInventor() != SdrInventor ||
pSingleObj->GetObjIdentifier() == OBJ_MEASURE) ) )



if((nTypeId == TYP_DDEFLD && pFldType->Which() == RES_DDEFLD) ||

((nTypeId == TYP_INPUTFLD || nTypeId == TYP_FORMELFLD) &&
(nWhich == RES_USERFLD ||
nWhich == RES_SETEXPFLD &&
!(((SwSetExpFieldType*)pFldType)->GetType() & nsSwGetSetExpType::GSE_SEQ)) ) )
{


The DEV300_m34 report, shows another drop from 1008 to 920 unused methods as mba’s workspace comes through to reduce framework and similar modules. Top 4 modules account for more than 50% of remaining low-hanging fruit

Unused methods dipped from 1411 to 1008 as most unused chart2 methods are removed, and a big pile of sc ones. leaving sd as the new leader module.

The unused method listings are updated for every release, i.e. the latest DEV300_m30.

The current un-integrated patches are listed here, with the largest set of unused code in sc scheduled for removal in workspace koheicoderemoval

The Windows Documentation has some confusion around the two different JIS and ISO B paper types.

   DMPAPER_B4        B4 (JIS) 250 x 354 mm
   DMPAPER_B5        B5 (JIS) 182 x 257 mm
   DMPAPER_ISO_B4    B4 (ISO) 250 x 353 mm
   DMPAPER_B6_JIS    B6 (JIS) 128 x 182 mm

i.e. DMPAPER_B5 is documented as JIS and the documented dimensions match that format. While DMPAPER_B4 is then documented as JIS but the documented dimensions match the ISO format B5 of 250 × 353 mm. Given the presence of DMPAPER_ISO_B4 and the absence of DMPAPER_B4_JIS I’ll bet that it is really the JIS size of 257 x 364, which is backed up by the PPD Specification stating that the Microsoft DMPAPER_B4 size is 257×364 and by the Microsoft Word UI which lists B4 (JIS) with (correct) dimensions of 257×364.

Turning our eyes to the Excel Documentation we have more confusion with the XlPaperSize enumeration. Here we have…

   xlPaperA5    A5 (148 mm x 210 mm)
   xlPaperB4    B4 (250 mm x 354 mm)
   xlPaperB5    A5 (148 mm x 210 mm)

Well what size is xlPaperB5 ? Is it truly ISO A5 (148 mm x 210 mm) like the comment says. Or might it be ISO B5, i.e. 176 × 250 mm. Or, seeing as the XlPaperSize enumeration has the same values as the DMPAPER values for all other values, are both xlPaperB4 and xlPaperB5 actually the same values as DMPAPER_B4 and DMPAPER_B5, which we’ve earlier determined are JIS B4 and B5 sizes, and not ISO sizes at all. That’s the most likely answer, i.e. the text is completely and totally wrong for xlPaperB4/xlPaperB5

At unicode.org the only locales listed as using Letter are the US and Canada.

Wikipedia agrees that only the US and Canada officially don’t use A4, but claims that in Mexico, Colombia, Chile and the Philippines Letter is nevertheless commonly used. Meanwhile at Microsoft the list of Letter using nations is: The US, Canada, Argentina, Brazil, Chile, Mexico, Venezuela and “Latin American countries”

As I’ve tried to document here, currently GTK thinks that the US, Canada and Puerto Rico are Letter users, while OpenOffice.org thinks that the list is the US, Canada, Mexico and Venezuela.

So, I still wonder, which nations excluding the US and Canada, would one truly find Letter as the true default in-use paper size.

A pleasing reduction of 160 methods from DEV300_m20 to DEV300_m24 as the package, goodies, embeddedobj, xmlhelp, basctl etc patches are integrated

Little Freya arrived (a week early) this morning at 02:30. I’ll be out of touch for a while

(I totally beat airlied past the post)

The DEV300_m19 callcatcher logs show a small but steady shrinkage improvement as more cleanup patches make their way into head.

In other news, I ported uno to m68k so OOo3 builds and functions on m68k under qemu. The sight of a running m68k OOo is somehow incredibly amusing.

Latest callcatcher results DEV300_m17 show a modest improvement as unused hwpfilter patch gets integrated, though there’s still an unused destructor, pointing more towards a potential resource leak where it should be used rather than get removed.

And DEV300_m14 results are available, with the integration of the binfilter fixes (thanks mba) unused symbol count has halved since DEV300_m13 and tumbles down the charts. I’ve extended callcatcher to understand basic map files so it can be used on non-terminal modules which have map files. Which extends the coverage to a further 25 modules.

See as gcc ate my starbasic with -fno-strict-aliasing it prompted me to check if we still need -fno-strict-aliasing anyway given all the warning cleanups of the last year. The short answer is definitely , but it looks doable to make it possible, and I’ve gotten it to at least launch with -fstrict-aliasing which should be sufficient to do some measurements on it next week to see if there is any measurable difference. Unfortunately while I can (probably) make Ooo -fstrict-aliasing good there are a gadzillion warnings from the stlport headers used on i386 builds so unless stlport was bumped up to one of the later versions where the warnings are fixed (or stlport dropped and gcc’s stl used like we did for x86_64) then only non-i386 users could get the benefit.

Some other random thoughts to look at to see if they’d matter a damn are:

• revisit the symbol ordering stuff again where symbols used during startup are sorted side by side in the .so
• Use -fshort-wchar and make a shadow struct for OUString which can take a
  wchar_t string to stick pre-created OUStrings into the rodata section.
• somehow magically convert non-public symbols to a shorter name and/or reversed strings