Re: [Libreoffice] minor idl fixes
On 04/20/2012 12:42 AM, Tomas Hlavaty wrote: 1) Exceptions have message and context fields and there should be a constructor with arguments (java.lang.String m, java.lang.Object c) for those fields. However, this doesn't seem to be applied consistently. Where is this not applied consistently? Also when an exception inherits, it should have a constructor with all fields for the super classes and itself. However, the context field is missing in such cases. Is there some rule to this or is it arbitrary? Looking at handleAggregatingType in codemaker/source/javamaker/javatype.cxx, for an exception three init methods (i.e., constructors) are generated, one with no parameters, one with just a String parameter (to be consistent with Java's overall Exception design), and one with parameters for all the (inherited and direct) members. 2) What is the meaning of 'published' in idl files? It seems to be ignored in javamaker, or at least everything gets generated no matter what. For example, there are enums or constants which are not marked as published but other public symbols depend on them. Shouldn't those be public too then? See slide 15 Published Things of the presentation http://www.openoffice.org/marketing/ooocon2004/presentations/friday/shinyhappyuno.pdf Here Come UNO, All Shiny and New for a short description of published (more extensive documentation appears to be lost to the Internet). That a published entity does not use unpublished entities is already checked by idlc, so the codemakers can ignore it. 3) What is the meaning of simgleton referring to service referring to interface? In the example bellow, the BrowseNodeFactory service doesn't seem to be generated from idl files. Should this service be bypassed and the singleton reffer directly to the interface? Old-style singleton specifications are indeed somewhat obscure. The need for a service is due to old implementation/design artefacts. New-style singleton specifications directly specify the interface they support, without going any service detour: singleton theBrowseNodeFactory: XBrowseNodeFactory; Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] minor idl fixes
Hi all,
bellow are some patches fixing minor issues with idl files.
Also I would like to ask:
1) Exceptions have message and context fields and there should be a
constructor with arguments (java.lang.String m, java.lang.Object c)
for those fields. However, this doesn't seem to be applied
consistently. Also when an exception inherits, it should have a
constructor with all fields for the super classes and itself.
However, the context field is missing in such cases. Is there some
rule to this or is it arbitrary?
2) What is the meaning of 'published' in idl files? It seems to be
ignored in javamaker, or at least everything gets generated no matter
what. For example, there are enums or constants which are not marked
as published but other public symbols depend on them. Shouldn't
those be public too then?
3) What is the meaning of simgleton referring to service referring to
interface? In the example bellow, the BrowseNodeFactory service
doesn't seem to be generated from idl files. Should this service be
bypassed and the singleton reffer directly to the interface?
module com { module sun { module star { module script { module browse {
interface XBrowseNodeFactory : ::com::sun::star::uno::XInterface {
com::sun::star::script::browse::XBrowseNode createView( [in] short
viewType );
};
}; }; }; }; };
module com { module sun { module star { module script { module browse {
service BrowseNodeFactory
{
interface XBrowseNodeFactory;
};
singleton theBrowseNodeFactory
{
service BrowseNodeFactory;
};
}; }; }; }; };
Thank you,
Tomas
From 0f8ee80872a99fa0cf903580c00b6b0ec1bc6491 Mon Sep 17 00:00:00 2001
From: Tomas Hlavaty t...@logand.com
Date: Mon, 16 Jan 2012 19:55:42 +0100
Subject: [PATCH 1/7] idl type reference fixed
---
offapi/com/sun/star/report/meta/XFormulaParser.idl |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/offapi/com/sun/star/report/meta/XFormulaParser.idl b/offapi/com/sun/star/report/meta/XFormulaParser.idl
index bc7575b..665f307 100644
--- a/offapi/com/sun/star/report/meta/XFormulaParser.idl
+++ b/offapi/com/sun/star/report/meta/XFormulaParser.idl
@@ -55,7 +55,7 @@ interface XFormulaParser
Names and symbols not defined here lead to a parser/print error.
*/
-[attribute] sequence sheet::FormulaOpCodeMapEntry OpCodeMap;
+[attribute] sequence com::sun::star::sheet::FormulaOpCodeMapEntry OpCodeMap;
/** return the mapper for op codes.
*/
--
1.7.5.4
From 518fd00501fc968872691b75a901dc718afa2ff7 Mon Sep 17 00:00:00 2001
From: Tomas Hlavaty t...@logand.com
Date: Sun, 22 Jan 2012 18:05:20 +0100
Subject: [PATCH 2/7] add missing #ifndef
---
udkapi/com/sun/star/corba/corba.idl |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/udkapi/com/sun/star/corba/corba.idl b/udkapi/com/sun/star/corba/corba.idl
index 45c239a..8f5d62b 100644
--- a/udkapi/com/sun/star/corba/corba.idl
+++ b/udkapi/com/sun/star/corba/corba.idl
@@ -25,6 +25,9 @@
* for a copy of the LGPLv3 License.
*
/
+#ifndef __com_sun_star_corba_corba_idl__
+#define __com_sun_star_corba_corba_idl__
+
module com { module sun { module star { module corba
{
/**
@@ -103,4 +106,6 @@ module com { module sun { module star { module corba
}; }; }; };
+#endif
+
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
--
1.7.5.4
From b2878038a08f3511c012451ab602d713ab0e1f1c Mon Sep 17 00:00:00 2001
From: Tomas Hlavaty t...@logand.com
Date: Tue, 24 Jan 2012 09:45:16 +0100
Subject: [PATCH 3/7] idl fix package for CorbaString8 and CorbaUnion
---
udkapi/com/sun/star/corba/giop/giop.idl | 10 +-
udkapi/com/sun/star/corba/iiop/iiop.idl |6 +++---
udkapi/com/sun/star/corba/iop/iop.idl |2 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/udkapi/com/sun/star/corba/giop/giop.idl b/udkapi/com/sun/star/corba/giop/giop.idl
index 1a8da38..a5b71fd 100644
--- a/udkapi/com/sun/star/corba/giop/giop.idl
+++ b/udkapi/com/sun/star/corba/giop/giop.idl
@@ -96,7 +96,7 @@ published struct RequestHeader_1_0
unsigned long request_id;
boolean response_expected;
sequence byte object_key;
-CorbaString8 operation;
+com::sun::star::corba::CorbaString8 operation;
sequence byte requesting_principal;
};
@@ -112,7 +112,7 @@ published struct RequestHeader_1_1
byte reserved_2;
byte reserved_3; // Added in GIOP 1.1
sequence byte object_key;
-CorbaString8 operation;
+com::sun::star::corba::CorbaString8 operation;
sequence byte requesting_principal; // binary compatible
};
@@ -138,7 +138,7 @@ published constants TargetAddressGroup
/**
@deprecated
*/
-published struct TargetAddress : CorbaUnion
+published struct TargetAddress :
Re: [Libreoffice] minor idl fixes
On 01/04/2012 11:09 PM, Tomas Hlavaty wrote:
diff --git a/offapi/com/sun/star/chart/XAxisSupplier.idl
b/offapi/com/sun/star/chart/XAxisSupplier.idl
index f87d245..cfb42b6 100644
--- a/offapi/com/sun/star/chart/XAxisSupplier.idl
+++ b/offapi/com/sun/star/chart/XAxisSupplier.idl
@@ -27,7 +27,7 @@
#ifndef com_sun_star_chart_XAxisSupplier_idl
#define com_sun_star_chart_XAxisSupplier_idl
-#include com/sun/star/chart/XAxis.idl
+#include com/sun/star/chart2/XAxis.idl
module com { module sun { module star { module chart {
@@ -43,7 +43,7 @@ interface XAxisSupplier : ::com::sun::star::uno::XInterface
@param nDimensionIndex
Parameter nDimensionIndex says wether it is a x, y or z-axis (0
for x).
*/
-com::sun::star::chart::XAxis getAxis( [in] long nDimensionIndex );
+com::sun::star::chart2::XAxis getAxis( [in] long nDimensionIndex );
/** @returns
the secondary axis of the specified dimension. The returned object supports
service typeChartAxis/type.
@@ -51,7 +51,7 @@ interface XAxisSupplier : ::com::sun::star::uno::XInterface
@param nDimensionIndex
Parameter nDimensionIndex says wether it is a x, y or z-axis (0
for x).
*/
-com::sun::star::chart::XAxis getSecondaryAxis( [in] long nDimensionIndex );
+com::sun::star::chart2::XAxis getSecondaryAxis( [in] long nDimensionIndex
);
};
}; }; }; };
Are you sure that this is right, using chart2 entities from within
chart? I always intuitively thought that chart2 was a second attempt,
to replace chart.
diff --git a/jurt/com/sun/star/comp/loader/JavaLoaderFactory.java
b/jurt/com/sun/star/comp/loader/JavaLoaderFactory.java
index 22981f2..eb45e7e 100644
--- a/jurt/com/sun/star/comp/loader/JavaLoaderFactory.java
+++ b/jurt/com/sun/star/comp/loader/JavaLoaderFactory.java
@@ -56,14 +56,14 @@ public class JavaLoaderFactory implements
XSingleServiceFactory, XServiceInfo {
multiServiceFactory = factory;
}
-public java.lang.Object createInstance()
+public com.sun.star.uno.XInterface createInstance()
throws com.sun.star.uno.Exception,
com.sun.star.uno.RuntimeException
{
return new JavaLoader(multiServiceFactory);
}
-public java.lang.Object createInstanceWithArguments( java.lang.Object[]
args )
+public com.sun.star.uno.XInterface createInstanceWithArguments(
java.lang.Object[] args )
throws com.sun.star.uno.Exception,
com.sun.star.uno.RuntimeException
{
and
diff --git a/jurt/com/sun/star/comp/loader/JavaLoader.java
b/jurt/com/sun/star/comp/loader/JavaLoader.java
index 25fc90b..3648fad 100644
--- a/jurt/com/sun/star/comp/loader/JavaLoader.java
+++ b/jurt/com/sun/star/comp/loader/JavaLoader.java
@@ -255,7 +255,7 @@ public class JavaLoader implements XImplementationLoader,
* @see com.sun.star.lang.XImplementationLoader
* @see com.sun.star.com.loader.RegistrationClassFinder
*/
-public java.lang.Object activate( String implementationName,
+public com.sun.star.uno.XInterface activate( String implementationName,
String implementationLoaderUrl,
String locationUrl,
XRegistryKey xKey )
@@ -264,7 +264,7 @@ public class JavaLoader implements XImplementationLoader,
{
locationUrl = expand_url( locationUrl );
-Object returnObject = null;
+com.sun.star.uno.XInterface returnObject = null;
Class clazz ;
DEBUG(try to get factory for + implementationName);
UNO XInterface maps to Java Object, see
http://wiki.services.openoffice.org/wiki/Uno/Java/Specifications/Type_Mapping.
Also, signatures of these methods must not be changed to avoid
backward incompatibility.
Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minor idl fixes
Hi Stephan, Stephan Bergmann sberg...@redhat.com writes: On 01/04/2012 11:09 PM, Tomas Hlavaty wrote: diff --git a/offapi/com/sun/star/chart/XAxisSupplier.idl b/offapi/com/sun/star/chart/XAxisSupplier.idl ... Are you sure that this is right, using chart2 entities from within chart? I always intuitively thought that chart2 was a second attempt, to replace chart. I am not sure as I don't know what chart and chart2 are about but currently this is broken. The patch fixes the compilation issue. Maybe I should move the file to chart2 package instead? diff --git a/jurt/com/sun/star/comp/loader/JavaLoaderFactory.java b/jurt/com/sun/star/comp/loader/JavaLoaderFactory.java -public java.lang.Object createInstance() +public com.sun.star.uno.XInterface createInstance() and diff --git a/jurt/com/sun/star/comp/loader/JavaLoader.java b/jurt/com/sun/star/comp/loader/JavaLoader.java -public java.lang.Object activate( String implementationName, +public com.sun.star.uno.XInterface activate( String implementationName, UNO XInterface maps to Java Object, see http://wiki.services.openoffice.org/wiki/Uno/Java/Specifications/Type_Mapping. Also, signatures of these methods must not be changed to avoid backward incompatibility. That's a good point. Any idea why XInterface is not used in all cases? Has it something to do with the fact that reference counting happens behind the scene in Java? Thank you, Tomas ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minor idl fixes
On 01/05/2012 09:38 AM, Tomas Hlavaty wrote: Stephan Bergmannsberg...@redhat.com writes: On 01/04/2012 11:09 PM, Tomas Hlavaty wrote: diff --git a/offapi/com/sun/star/chart/XAxisSupplier.idl b/offapi/com/sun/star/chart/XAxisSupplier.idl ... Are you sure that this is right, using chart2 entities from within chart? I always intuitively thought that chart2 was a second attempt, to replace chart. I am not sure as I don't know what chart and chart2 are about but currently this is broken. The patch fixes the compilation issue. Maybe I should move the file to chart2 package instead? What exactly is broken? [...] That's a good point. Any idea why XInterface is not used in all cases? Has it something to do with the fact that reference counting happens behind the scene in Java? No, just some (somewhat bad) design decision early on in the life of UNO. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minor idl fixes
Hi Tomas, On Wed, 2012-01-04 at 23:09 +0100, Tomas Hlavaty wrote: sorry for inconvenience, I have sent the License statement email to the mailing list so please feel free to reapply the patch. Thanks ! - I pushed it to master; it also seems to be in the 3.5 branch, so hopefully it should be there too for you in the release :-) All the best, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minor idl fixes
On 05/01/12 09:38, Tomas Hlavaty wrote: Hi Stephan, Stephan Bergmann sberg...@redhat.com writes: On 01/04/2012 11:09 PM, Tomas Hlavaty wrote: diff --git a/offapi/com/sun/star/chart/XAxisSupplier.idl b/offapi/com/sun/star/chart/XAxisSupplier.idl ... Are you sure that this is right, using chart2 entities from within chart? I always intuitively thought that chart2 was a second attempt, to replace chart. I am not sure as I don't know what chart and chart2 are about but currently this is broken. The patch fixes the compilation issue. Maybe I should move the file to chart2 package instead? argh... that would not work, because there is already a chart2::XAxis. in addition to chart::XAxis. actually the chart::XAxis is newer than chart2::XAxis: it was added for OOo 3.4, in commit 0c1fb57fe1588ba0d2ed07145fd07e834c96623f the implementation of this is in chart2/source/controller/chartapiwrapper/DiagramWrapper.cxx, and it uses chart::XAxis. by now i'm now pretty confused, but i think the proposed patch is wrong. ah, your trouble could be caused by chart/XAxis.idl and chart2/XAxis.idl having the same include guard, i'll try to fix that... grmbl, what a mess... ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minor idl fixes
Hi Stephan, Stephan Bergmann sberg...@redhat.com writes: On 01/05/2012 09:38 AM, Tomas Hlavaty wrote: Stephan Bergmannsberg...@redhat.com writes: On 01/04/2012 11:09 PM, Tomas Hlavaty wrote: diff --git a/offapi/com/sun/star/chart/XAxisSupplier.idl What exactly is broken? as Michael Stahl noticed and fixed, the include guard copypaste. Any idea why XInterface is not used in all cases? Has it something to do with the fact that reference counting happens behind the scene in Java? No, just some (somewhat bad) design decision early on in the life of UNO. OK, thank you for your feedback! Regards, Tomas ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minor idl fixes
Hi Michael, Michael Meeks michael.me...@suse.com writes: Thanks ! - I pushed it to master; it also seems to be in the 3.5 branch, so hopefully it should be there too for you in the release :-) Thank you! Tomas ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minor idl fixes
Hi Michael,
Until then I'll reverting the patch, in case I forget later; we
wouldn't like to accidentally license your code against your wishes.
sorry for inconvenience, I have sent the License statement email to the
mailing list so please feel free to reapply the patch.
Also, I attach a few more patches.
Thank you,
Tomas
From da9fb395502bb2066db60dd4e69a6c69a5d8bb8f Mon Sep 17 00:00:00 2001
From: Tomas Hlavaty t...@logand.com
Date: Thu, 15 Dec 2011 23:57:19 +0100
Subject: [PATCH 1/7] fix broken ifndef/define guard in idl
---
.../star/frame/DoubleInitializationException.idl |4 ++--
.../sun/star/frame/IllegalArgumentIOException.idl |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/offapi/com/sun/star/frame/DoubleInitializationException.idl b/offapi/com/sun/star/frame/DoubleInitializationException.idl
index d225770..f716e3e 100644
--- a/offapi/com/sun/star/frame/DoubleInitializationException.idl
+++ b/offapi/com/sun/star/frame/DoubleInitializationException.idl
@@ -24,8 +24,8 @@
* for a copy of the LGPLv3 License.
*
/
-#ifndef __com_sun_star_frame_TerminationVetoException_idl__
-#define __com_sun_star_frame_TerminationVetoException_idl__
+#ifndef __com_sun_star_frame_DoubleInitializationException_idl__
+#define __com_sun_star_frame_DoubleInitializationException_idl__
#include com/sun/star/uno/Exception.idl
diff --git a/offapi/com/sun/star/frame/IllegalArgumentIOException.idl b/offapi/com/sun/star/frame/IllegalArgumentIOException.idl
index a0bef81..9c0ccd8 100644
--- a/offapi/com/sun/star/frame/IllegalArgumentIOException.idl
+++ b/offapi/com/sun/star/frame/IllegalArgumentIOException.idl
@@ -24,8 +24,8 @@
* for a copy of the LGPLv3 License.
*
/
-#ifndef __com_sun_star_frame_TerminationVetoException_idl__
-#define __com_sun_star_frame_TerminationVetoException_idl__
+#ifndef __com_sun_star_frame_IllegalArgumentIOException_idl__
+#define __com_sun_star_frame_IllegalArgumentIOException_idl__
#include com/sun/star/io/IOException.idl
--
1.7.0.4
From 2172e7435d5b067e1bf25c8906852c74a1c3322c Mon Sep 17 00:00:00 2001
From: Tomas Hlavaty t...@logand.com
Date: Sat, 17 Dec 2011 17:42:58 +0100
Subject: [PATCH 2/7] fix package in idl
---
offapi/com/sun/star/chart/XAxisSupplier.idl |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/offapi/com/sun/star/chart/XAxisSupplier.idl b/offapi/com/sun/star/chart/XAxisSupplier.idl
index f87d245..cfb42b6 100644
--- a/offapi/com/sun/star/chart/XAxisSupplier.idl
+++ b/offapi/com/sun/star/chart/XAxisSupplier.idl
@@ -27,7 +27,7 @@
#ifndef com_sun_star_chart_XAxisSupplier_idl
#define com_sun_star_chart_XAxisSupplier_idl
-#include com/sun/star/chart/XAxis.idl
+#include com/sun/star/chart2/XAxis.idl
module com { module sun { module star { module chart {
@@ -43,7 +43,7 @@ interface XAxisSupplier : ::com::sun::star::uno::XInterface
@param nDimensionIndex
Parameter nDimensionIndex says wether it is a x, y or z-axis (0 for x).
*/
-com::sun::star::chart::XAxis getAxis( [in] long nDimensionIndex );
+com::sun::star::chart2::XAxis getAxis( [in] long nDimensionIndex );
/** @returns
the secondary axis of the specified dimension. The returned object supports service typeChartAxis/type.
@@ -51,7 +51,7 @@ interface XAxisSupplier : ::com::sun::star::uno::XInterface
@param nDimensionIndex
Parameter nDimensionIndex says wether it is a x, y or z-axis (0 for x).
*/
-com::sun::star::chart::XAxis getSecondaryAxis( [in] long nDimensionIndex );
+com::sun::star::chart2::XAxis getSecondaryAxis( [in] long nDimensionIndex );
};
}; }; }; };
--
1.7.0.4
From 287b3f61c9d4930c26a1235e0e2cd1c1ac3dded1 Mon Sep 17 00:00:00 2001
From: Tomas Hlavaty t...@logand.com
Date: Sat, 17 Dec 2011 17:45:13 +0100
Subject: [PATCH 3/7] idl fix package names
---
offapi/com/sun/star/chart2/InterpretedData.idl |2 +-
offapi/com/sun/star/chart2/ScaleData.idl |2 +-
offapi/com/sun/star/chart2/XChartDocument.idl |2 +-
offapi/com/sun/star/chart2/XChartTypeTemplate.idl |4 ++--
offapi/com/sun/star/chart2/XDataInterpreter.idl|4 ++--
offapi/com/sun/star/chart2/XDiagram.idl|2 +-
.../com/sun/star/chart2/XInternalDataProvider.idl |2 +-
.../com/sun/star/xml/sax/XFastSAXSerializable.idl |8
offapi/com/sun/star/xml/sax/XSAXSerializable.idl |4 ++--
9 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/offapi/com/sun/star/chart2/InterpretedData.idl b/offapi/com/sun/star/chart2/InterpretedData.idl
index 0eedd9c..281bac9 100644
--- a/offapi/com/sun/star/chart2/InterpretedData.idl
+++ b/offapi/com/sun/star/chart2/InterpretedData.idl
@@ -50,7 +50,7 @@ struct InterpretedData
/**
*/
-
Re: [Libreoffice] minor idl fixes
On 12/13/2011 01:21 AM, Tomas Hlavaty wrote: Stephan Bergmannsberg...@redhat.com writes: At runtime, the C++ UNO binding queries the types.rdb for certain data (e.g., when (un-)packing data as ANY). OK. Does it need to go through the rdb file? It could as well be already compiled into a dll. Yes, but duplicating information has disadvantages. The main problem that I see here is .oxt extensions that bring along additional UNO types. If a UNO language binding relies on runtime type information being available in any format other than the common .rdb format, each such extension needs to include that language-specific data alongside its common .rdb data. This is a burden for extension developers, and does not scale with the introduction of new language bindings. The Java way of relying on Java .class files instead of .rdb has been identified as a mistake. Binding UNO to dynamic languages like Python takes another approach. It obtains any necessary information purely at runtime, from the types.rdb, via UNO services that make available that information. It does not require any *maker tool to generate language-specific artefacts from the complete type information upfront. OK. But it could be made faster if the type information was available in one go instead of querying per instance, if the speed was a problem? So we could have the type information in a readable format or generated as a py file. Or maybe everybody is happy with the way python does it? I think the less one needs to generate upfront, the easier the overall workflow becomes. What about StarBasic? I guess that would be similar to Python. Yes, it mainly uses a UNO invocation service that obtains a UNO object reference, name of what to invoke (interface function, property setter/getter), and arguments, and handles all the minute details internally. Another point to re-evaluate is how much of that complete type information to duplicate in the artefacts generated for the various language bindings. Why not all? It's not that much. See above. On the one hand, it might be advantageous to encode more information in the generated C++ artefacts (potentially even generating a dedicated dynamic library containing the relevant, instead of spreading it inlined across header files, where the linker can recombine part of it again). That could help ensure that the (new-style) types.rdb need not be read early on during startup (so if loading it where somewhat costly that would not be that much of a problem as it is today). Yes. But wouldn't be the type database still required as C++ doesn't have the reflection capability built-in? Yes, of course. This would purely be a performance improvement, with the trade-off of duplicating information for speed. (And as all information would still be available in .rdb, this would have no implications for extensions. Whenever information about a type is needed for which there is no statically cached direct C++ data, the language binding would fall back to the---slower---.rdb data.) On the other hand, an easily parsable format would allow Java to reduce the amount of information currently stored in generated .class files, and instead rely on the complete type information available as a (new-style) types.rdb. Java .class files could even be generated on the fly from the types.rdb information using a dedicated Java class loader. (That would remove the ugly requirement that .oxt extensions need to bring their additional UNO types as both .rdb and .class files.) Here I don't know how these .oxt extensions work. Is the size of generated .class files an issue? No, see above. Though idlc, climaker, javamaker, codemaker would just be replaced with your new code (that conceptually does the same thing), if I get you right? Exactly;-) But why rewrite climaker, javamaker, codemaker then? As they take their information from the interface abstracting from the actual .rdb format, they can be left unchanged (or enhanced to emit additional information, if so desired). (Note that module idl is completely unrelated to UNO.) What is it then? It looks like something related to idl compilation. That other idl describes user interface resources. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minor idl fixes
Hi Tomas, On Tue, 2011-12-13 at 00:52 +0100, Tomas Hlavaty wrote: that they are tiny, What does tiny mean? Well - you're going to find it hard to make it bigger than the existing rdb files ;-) but by tiny I really mean fast to read from disk and fast to parse. Currently, rdb files are giant. Sure; they are a disaster :-) I'm not sure why. If I simply concatenate all idl definitions for udkapi and offapi into one preprocessed file I get smaller file while still being a valid idl file containing all the information: Yep; this is well known. It is all done re-using some code not intended for thus purpose, which has been tweaked to the maximum to try to make it suit it better, but it still doesn't ;-) Is 200kB considered tiny? Sounds fine :-) And this is just original concatenated idl files. Sure - sounds fine; if we can parse it fast. How long does reading the type information take at the moment? That's quite hard to say; access to it is extremely scattered across the code. callgrind gives 1.5% in libreg, 0.6% in libstore and some lowish proportion of the 32% in libuno_sal; say perhaps 2.5%. That IMHO hides it's true cost - we have to force pagein all that data before start to avoid horrible I/O patterns mmap gives us as we seek about in those big files. What do we get to do a lot at startup? I thought we simply load it an that's it. Sure; we load it that is it *but* we would really like to be starting in total in under a second, at least making choices that hurt that goal on a fast PC are almost certain to also hurt the goal of working well on mobile devices etc. :-) If the new format is a text format (I would prefer text format over another binary one), there needs to be some parsing. unoidl2 can parse the allpp.idl file (containing all type information) and print the syntax tree in about 200ms: $ rm allpp.ast $ time make allpp.ast cat allpp.idl | ./unoidl2ast allpp.ast real 0m0.247s user 0m0.170s sys 0m0.100s 250ms is a -really- long time IMHO; particularly since we have to parse the entire file before startup. As Stephan says, perhaps we can overcome this by inlining more in the generated C++ which may make that acceptable later (after all bootstrapping python takes a good long time itself anyway). If 200ms is slow, we could split the allpp,idl file into something smaller required at startup and the rest loaded lazily. Possibly; or we could invent yet another format for this type information. Personally, I'd like to keep the number of representations of the same information as low as possible: we already have IDL, we have the binaryurp format [ used for IPC on the wire ] (potentially we could re-use that?), do we have an XML/text IPC protocol ? I suspect we will want that for the remote Javascript/websockets magic - possibly we could use a condensed XML format for this that'd be quicker to parse ? unclear. Stephan - do you have some ideas ? as soon as I see a yacc parser, I see slow and busts the branch predictor - but perhaps I'm paranoid ;-) We could have a binary format, something like a mmap dump. That would be instant but rather ugly. Sure - that'd be bad :-) I like the 'concatenate text files' approach for building the the database (personally). Are there any other requirements? Like functionality related to rdbmerge and how extensibility works? Or is that not relevant anymore? rdbmerge is/was IIRC just a compile-time tool. Clearly we need to continue to be able to read old types.rdb files for some time to come, but that can be de-coupled and removed later I think. I was under impression that these projects somehow depend on the rdb code, but if they depend on the typedescription api, then it is better then I hoped (if that typedescription api is somehow separate from the rdb file code). Sure - there is only one place that we go grubbing with that nasty rdb format - and it's at the bottom of the stack :-) if we can hot plug that out with something else, life is good :-) Thanks, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minor idl fixes
On 12/13/2011 11:15 AM, Michael Meeks wrote: On Tue, 2011-12-13 at 00:52 +0100, Tomas Hlavaty wrote: If 200ms is slow, we could split the allpp,idl file into something smaller required at startup and the rest loaded lazily. Possibly; or we could invent yet another format for this type information. Personally, I'd like to keep the number of representations of the same information as low as possible: we already have IDL, we have the binaryurp format [ used for IPC on the wire ] (potentially we could re-use that?), do we have an XML/text IPC protocol ? I suspect we will want that for the remote Javascript/websockets magic - possibly we could use a condensed XML format for this that'd be quicker to parse ? unclear. Stephan - do you have some ideas ? as soon as I see a yacc parser, I see slow and busts the branch predictor - but perhaps I'm paranoid ;-) Note that URP does not transport any type information. For a first iteration I would go with a radically stripped down UNOIDL syntax (which is useful in and of itself, anyway) and .rdb being in that format. If it is too slow, improve the C++ UNO language binding by redundantly pre-computing data into a dynamic library. I was under impression that these projects somehow depend on the rdb code, but if they depend on the typedescription api, then it is better then I hoped (if that typedescription api is somehow separate from the rdb file code). Sure - there is only one place that we go grubbing with that nasty rdb format - and it's at the bottom of the stack :-) if we can hot plug that out with something else, life is good :-) Tomas, if you are interested, you can study how I switched the UNO service information data from an old .rdb format to an XML-based one at the bottom of that abstraction stack. SimpleRegistry::open in stoc/source/simpleregistry/simpleregistry.cxx first tries the old way (for backwards compatibility with old .oxt extensions that have their service information still stored in old-style .rdb files) and if that fails, tries to read via the new TextualServices stuff. If we have a new format not only for services, but also a new one for types, we need to extend that code, to either open via TextualServices or via some new TextualTypes, say. For this, it would be good if there were an easy and fast discrimination between the two file formats (like if it starts with ?xml pass it to TextualServices, otherwise to TextualTypes). Since the old concept used the .rdb format for both service and type information, the code to access either uses common abstraction layers, that therefore have to be able to deal with both new formats. Only once everything works well should we try to get rid of the common abstraction layers atop the two new formats (the UNO com.sun.star.registry abstraction stuff). --- Potentially for LO 4, when we need no longer care about backwards compatibility, which is a pain here. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minor idl fixes
Hi Thomas, On Sat, 2011-12-10 at 14:57 +0100, Tomas Hlavaty wrote: I would be happy with LGPLv3+ but I haven't found much on why was MPL added and/or preffered for new contributions. Could you please point me to some discussions so I can make up my mind on this matter? Sure; so - the MPL is primarily there to make LibreOffice more friendly to companies, such as IBM, who have an aversion to the LGPLv3 - and with whom we hope to eventually reconcile into one big happy, copy-left family again. It is a rather weaker copy-left license, and doesn't seem to have done much harm to Firefox ;-) Making your code available under it has been a criteria for including code into LibreOffice from our launch. As you say, prolly we should have a write-up on that somewhere. Having a just a few patches under a different license is rather a problem - as/when the ASF manage to get OO.o under the AL2 license, we'll do a big license/header change across the whole codebase, and then (hopefully) stop having to ask everyone for this. There seems to be agreement that the RDB type database should go away. There are several LO projects that would be affected by this and they seem rather complex with dependencies. Oooh - it'd be great to have some work on that :-) As a proof of concept, I have created a unoidl2 project: git clone http://logand.com/git/unoidl2.git ... This would allow us to get rid of the RDB files (although I need to familiarise myself with current use-cases to understand the impact of such change, e.g. merging in custom plugins). So, there are rather a number of hidden criteria for RDB files: that they are tiny, instant to parse (and/or don't require parsing) - since we get to do this quite a lot at startup (which is already not as performant as it could be ;-). The data needs to be in a small (read three or less) number of files - to avoid I/O seek latency on rotating media. The other affected LO projects would likely be: Well all of these other guys -should- work on top of the typedescription API (I would hope), so as long as that is in-place, life will be good I think. It might be interesting to generate vapi file for vala programming language, for example. Are there any examples of connection to libreoffice from plain C? Sadly, the plain-C UNO bridge died a death some years back I think; though this was originally intended to be possible [ the base sal/ library still has a C ABI/API ]. HTH, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minor idl fixes
On 12/10/2011 02:57 PM, Tomas Hlavaty wrote: There seems to be agreement that the RDB type database should go away. There are several LO projects that would be affected by this and they seem rather complex with dependencies. Also, for example the conversion from uno idl to java and cli goes directly to the binary format (class file, assembly) and it's hard to see what they actually generate. As a proof of concept, I have created a unoidl2 project: git clone http://logand.com/git/unoidl2.git Note that it doesn't work yet but already has the parsing part in place, i.e. can generate ast and has an incomplete unoidl2java generation. The idea is that there would be a collection of small programs that would convert uno idl files to different languages, e.g. unoidl2java, unoidl2cs, unoidl2vala, unoidl2xml, unoidl2py etc. These programs should be as simple as possible with no dependencies so that anybody can write a new uno idl converter for his programming language easily. Historically, the situation is as follows: On the one hand, there is a types.rdb (or split across a handful of such) that stores all the UNOIDL type information in a binary format. Its information content is thus, in a sense, isomorphic to the collection of the .idl files. In the following, I'll call this the complete type information. On the other hand, the UNO binding for a given language in some cases needs part of that UNOIDL type information mapped to constructs of the given language: The C++ UNO binding requires C++ class definitions for the UNOIDL interface, struct, exception, etc. types. For this, cppumaker extracts some of the data from the complete type information and generates the relevant C++ class definitions from it, in the form of C++ header files. Note that typically not the complete type information is encoded in those header files (though there are switches to cppumaker to control the degree of included information, mainly for purposes of bootstrapping a UNO environment at runtime). At runtime, the C++ UNO binding queries the types.rdb for certain data (e.g., when (un-)packing data as ANY). The Java UNO binding requires Java class files for the UNOIDL interface, struct, exception, etc. types. For this, javamaker extracts (almost) the complete type information and generates Java class files from it. (It does not go via .java source files so it could simultaneously support Java 4 and new Java 5 features at a time when that was still relevant.) At runtime, the Java UNO binding never needs to query the types.rdb (and there's no Java code that can read that format) -- the information encoded in the .class files is rich enough for all the binding's demands. Binding UNO to dynamic languages like Python takes another approach. It obtains any necessary information purely at runtime, from the types.rdb, via UNO services that make available that information. It does not require any *maker tool to generate language-specific artefacts from the complete type information upfront. So, I think there is still demand to make available the complete type information at runtime. Just the format of binary .rdb files is rather inconvenient. My point of view is to replace the binary .rdb format with a simpler, most likely textual format (for which easy reading can be implemented in any language, if need be). One viable approach seems to be to streamline the current .idl file format and directly use that syntax for any new-style .rdb files (catenating together the individual .idl files into a large .rdb file, say). Another point to re-evaluate is how much of that complete type information to duplicate in the artefacts generated for the various language bindings. On the one hand, it might be advantageous to encode more information in the generated C++ artefacts (potentially even generating a dedicated dynamic library containing the relevant, instead of spreading it inlined across header files, where the linker can recombine part of it again). That could help ensure that the (new-style) types.rdb need not be read early on during startup (so if loading it where somewhat costly that would not be that much of a problem as it is today). On the other hand, an easily parsable format would allow Java to reduce the amount of information currently stored in generated .class files, and instead rely on the complete type information available as a (new-style) types.rdb. Java .class files could even be generated on the fly from the types.rdb information using a dedicated Java class loader. (That would remove the ugly requirement that .oxt extensions need to bring their additional UNO types as both .rdb and .class files.) LO projects like registry, rdbmaker, regview, regmerge, idl, idlc, climaker, javamaker, codemaker would be deprecated. Though idlc, climaker, javamaker, codemaker would just be replaced with your new code (that conceptually does the same thing), if I
Re: [Libreoffice] minor idl fixes
Hi Michael, This would allow us to get rid of the RDB files (although I need to familiarise myself with current use-cases to understand the impact of such change, e.g. merging in custom plugins). So, there are rather a number of hidden criteria for RDB files: that they are tiny, What does tiny mean? Currently, rdb files are giant. 49 2011-07-12 21:36 /var/lib/openoffice/basis3.2/program/services.rdb 2031616 2011-01-26 23:32 /usr/lib/openoffice/basis3.2/program/oovbaapi.rdb 6520832 2011-01-26 23:31 /usr/lib/openoffice/basis3.2/program/offapi.rdb 262144 2011-01-27 00:17 /usr/lib/ure/share/misc/services.rdb 851968 2011-01-26 23:29 usr/lib/ure/share/misc/types.rdb I'm not sure why. If I simply concatenate all idl definitions for udkapi and offapi into one preprocessed file I get smaller file while still being a valid idl file containing all the information: 1695058 2011-12-12 23:55 allpp.idl The makefile rules for allpp.idl file goes along this line: offapi.list: find $(LIBO)/offapi/ -name '*.idl' $@ udkapi.list: find $(LIBO)/udkapi/ -name '*.idl' $@ all.list: offapi.list udkapi.list cat udkapi.list offapi.list $@ all.idl: all.list sed -e s@/opt/libo/udkapi/@@g -e s@/opt/libo/offapi/@@g -e s@.*@#include @g $ $@ allpp.idl: all.idl cpp -P -I$(LIBO)/offapi -I$(LIBO)/udkapi $ $@ If I compress allpp.idl I get rather small file containing complete type information for udkapi and offapi: 212524 2011-12-12 23:55 allpp.idl.gz Is 200kB considered tiny? And this is just original concatenated idl files. instant to parse (and/or don't require parsing) - since we get to do this quite a lot at startup (which is already not as performant as it could be ;-). How long does reading the type information take at the moment? What do we get to do a lot at startup? I thought we simply load it an that's it. If the new format is a text format (I would prefer text format over another binary one), there needs to be some parsing. unoidl2 can parse the allpp.idl file (containing all type information) and print the syntax tree in about 200ms: $ rm allpp.ast $ time make allpp.ast cat allpp.idl | ./unoidl2ast allpp.ast real 0m0.247s user 0m0.170s sys 0m0.100s I think that should be about the worst case achievable, since any cleverer format than the original idl syntax should be faster to parse. But maybe the difference won't be significant. If 200ms is slow, we could split the allpp,idl file into something smaller required at startup and the rest loaded lazily. We could have a binary format, something like a mmap dump. That would be instant but rather ugly. The data needs to be in a small (read three or less) number of files - to avoid I/O seek latency on rotating media. OK. Are there any other requirements? Like functionality related to rdbmerge and how extensibility works? Or is that not relevant anymore? The other affected LO projects would likely be: Well all of these other guys -should- work on top of the typedescription API (I would hope), so as long as that is in-place, life will be good I think. I was under impression that these projects somehow depend on the rdb code, but if they depend on the typedescription api, then it is better then I hoped (if that typedescription api is somehow separate from the rdb file code). Sadly, the plain-C UNO bridge died a death some years back I think; though this was originally intended to be possible [ the base sal/ library still has a C ABI/API ]. OK, I'll have a look at sal. Thank you, Tomas ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minor idl fixes
Hi Stephan, Stephan Bergmann sberg...@redhat.com writes: Historically, the situation is as follows: thanks a lot! At runtime, the C++ UNO binding queries the types.rdb for certain data (e.g., when (un-)packing data as ANY). OK. Does it need to go through the rdb file? It could as well be already compiled into a dll. class files from it. (It does not go via .java source files so it could simultaneously support Java 4 and new Java 5 features at a time when that was still relevant.) I see. Binding UNO to dynamic languages like Python takes another approach. It obtains any necessary information purely at runtime, from the types.rdb, via UNO services that make available that information. It does not require any *maker tool to generate language-specific artefacts from the complete type information upfront. OK. But it could be made faster if the type information was available in one go instead of querying per instance, if the speed was a problem? So we could have the type information in a readable format or generated as a py file. Or maybe everybody is happy with the way python does it? What about StarBasic? I guess that would be similar to Python. My point of view is to replace the binary .rdb format with a simpler, most likely textual format (for which easy reading can be implemented in any language, if need be). One viable approach seems to be to streamline the current .idl file format and directly use that syntax for any new-style .rdb files (catenating together the individual .idl files into a large .rdb file, say). Agree. This is what I did in the unoidl2 project I mentioned in previous emails. Another point to re-evaluate is how much of that complete type information to duplicate in the artefacts generated for the various language bindings. Why not all? It's not that much. On the one hand, it might be advantageous to encode more information in the generated C++ artefacts (potentially even generating a dedicated dynamic library containing the relevant, instead of spreading it inlined across header files, where the linker can recombine part of it again). That could help ensure that the (new-style) types.rdb need not be read early on during startup (so if loading it where somewhat costly that would not be that much of a problem as it is today). Yes. But wouldn't be the type database still required as C++ doesn't have the reflection capability built-in? On the other hand, an easily parsable format would allow Java to reduce the amount of information currently stored in generated .class files, and instead rely on the complete type information available as a (new-style) types.rdb. Java .class files could even be generated on the fly from the types.rdb information using a dedicated Java class loader. (That would remove the ugly requirement that .oxt extensions need to bring their additional UNO types as both .rdb and .class files.) Here I don't know how these .oxt extensions work. Is the size of generated .class files an issue? 3680 2011-01-26 23:31 java/openoffice/unoloader.jar 108139 2011-01-26 23:31 java/openoffice/jurt.jar 4207 2011-01-26 23:33 java/openoffice/java_uno.jar 55519 2011-01-26 23:35 java/openoffice/juh.jar 258511 2011-01-26 23:31 java/openoffice/ridl.jar 448964 2009-11-23 23:38 java/gnome-java-bridge.jar Those jar files seem reasonably small. LO projects like registry, rdbmaker, regview, regmerge, idl, idlc, climaker, javamaker, codemaker would be deprecated. Though idlc, climaker, javamaker, codemaker would just be replaced with your new code (that conceptually does the same thing), if I get you right? Exactly;-) (Note that module idl is completely unrelated to UNO.) What is it then? It looks like something related to idl compilation. As Micheal already pointed out, changes to the .rdb format would best be kept behind the existing interfaces abstracting from it, so that those client modules would hardly notice. Great if that's the case. Do we have a better documentation on type mappings then for example http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/Type_Mappings? For Java I once detailed that at http://wiki.services.openoffice.org/wiki/Uno/Java/Specifications/Type_Mapping (and the UNO type system itself at http://udk.openoffice.org/common/man/typesystem.html). Thank you for the links! Cheers, Tomas ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minor idl fixes
Hi Michael, Nice work - thanks :-) It'd be great if you could give an explicit licensing statement for your contributions; something like: All my contributions to LibreOffice are licensed under the MPL/LGPLv3+ dual license or somesuch :-) then we can add you to: http://wiki.documentfoundation.org/Development/Developers Which helps smooth the flow. Anyhow - great to have you contributing I would be happy with LGPLv3+ but I haven't found much on why was MPL added and/or preffered for new contributions. Could you please point me to some discussions so I can make up my mind on this matter? is there any particular piece you'd like to work on ? or annoying bug you'd like to fix ? :-) There seems to be agreement that the RDB type database should go away. There are several LO projects that would be affected by this and they seem rather complex with dependencies. Also, for example the conversion from uno idl to java and cli goes directly to the binary format (class file, assembly) and it's hard to see what they actually generate. As a proof of concept, I have created a unoidl2 project: git clone http://logand.com/git/unoidl2.git Note that it doesn't work yet but already has the parsing part in place, i.e. can generate ast and has an incomplete unoidl2java generation. The idea is that there would be a collection of small programs that would convert uno idl files to different languages, e.g. unoidl2java, unoidl2cs, unoidl2vala, unoidl2xml, unoidl2py etc. These programs should be as simple as possible with no dependencies so that anybody can write a new uno idl converter for his programming language easily. This would allow us to get rid of the RDB files (although I need to familiarise myself with current use-cases to understand the impact of such change, e.g. merging in custom plugins). LO projects like registry, rdbmaker, regview, regmerge, idl, idlc, climaker, javamaker, codemaker would be deprecated. It would also work with text files only (and the results could be commited into the repository for easier inspection of changes). Conversion to java class files and .NET assemblies would be delegated to dedicated compilers (javac, csc). The other affected LO projects would likely be: - binaryurp - bridges - cli_ure - cppu - cppuhelper - javaunohelper - pyuno (native?) - ridljar - scripting - unodevtools - unoil although there is little information on what some projects are supposed to do and how people use them. Do we have a better documentation on type mappings then for example http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/Type_Mappings? It might be interesting to generate vapi file for vala programming language, for example. Are there any examples of connection to libreoffice from plain C? Thank you, Tomas ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minor idl fixes
Hi Thomas, On Wed, 2011-12-07 at 00:02 +0100, Tomas Hlavaty wrote: attached is a patch to fix some broken IDL files. Nice work - thanks :-) It'd be great if you could give an explicit licensing statement for your contributions; something like: All my contributions to LibreOffice are licensed under the MPL/LGPLv3+ dual license or somesuch :-) then we can add you to: http://wiki.documentfoundation.org/Development/Developers Which helps smooth the flow. Anyhow - great to have you contributing - is there any particular piece you'd like to work on ? or annoying bug you'd like to fix ? :-) All the best, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] minor idl fixes
Hi all,
attached is a patch to fix some broken IDL files.
Thank you,
Tomas
From d66bf0eea556f71b25c526e7916d7aaea739c8a8 Mon Sep 17 00:00:00 2001
From: Tomas Hlavaty t...@logand.com
Date: Tue, 6 Dec 2011 23:52:56 +0100
Subject: [PATCH] minor idl fixes
---
.../sun/star/drawing/DrawingDocumentFactory.idl|2 +-
.../com/sun/star/i18n/XExtendedTransliteration.idl |2 +-
offapi/com/sun/star/i18n/XNativeNumberSupplier.idl |2 +-
.../com/sun/star/linguistic2/LanguageGuessing.idl |2 +-
udkapi/com/sun/star/util/logging/Logger.idl|4 ++--
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/offapi/com/sun/star/drawing/DrawingDocumentFactory.idl b/offapi/com/sun/star/drawing/DrawingDocumentFactory.idl
index 41bbd29..71d3231 100644
--- a/offapi/com/sun/star/drawing/DrawingDocumentFactory.idl
+++ b/offapi/com/sun/star/drawing/DrawingDocumentFactory.idl
@@ -26,7 +26,7 @@
**
**/
#ifndef __com_sun_star_drawing_DrawingDocumentFactory_idl__
-#define __com::sun::star::drawing_DrawingDocumentFactory_idl__
+#define __com_sun_star_drawing_DrawingDocumentFactory_idl__
#include com/sun/star/lang/XMultiServiceFactory.idl
diff --git a/offapi/com/sun/star/i18n/XExtendedTransliteration.idl b/offapi/com/sun/star/i18n/XExtendedTransliteration.idl
index ca2348d..3afe7c8 100644
--- a/offapi/com/sun/star/i18n/XExtendedTransliteration.idl
+++ b/offapi/com/sun/star/i18n/XExtendedTransliteration.idl
@@ -29,7 +29,7 @@
#define __com_sun_star_i18n_XExtendedTransliteration_idl__
#include com/sun/star/i18n/XTransliteration.idl
-#include MultipleCharsOutputException.idl
+#include com/sun/star/i18n/MultipleCharsOutputException.idl
//=
diff --git a/offapi/com/sun/star/i18n/XNativeNumberSupplier.idl b/offapi/com/sun/star/i18n/XNativeNumberSupplier.idl
index a11ad7a..2e96883 100644
--- a/offapi/com/sun/star/i18n/XNativeNumberSupplier.idl
+++ b/offapi/com/sun/star/i18n/XNativeNumberSupplier.idl
@@ -29,7 +29,7 @@
#define __com_sun_star_i18n_XNativeNumberSupplier_idl__
#include com/sun/star/lang/Locale.idl
-#include NativeNumberXmlAttributes.idl
+#include com/sun/star/i18n/NativeNumberXmlAttributes.idl
//=
diff --git a/offapi/com/sun/star/linguistic2/LanguageGuessing.idl b/offapi/com/sun/star/linguistic2/LanguageGuessing.idl
index 1e99fbc..5ba3c04 100644
--- a/offapi/com/sun/star/linguistic2/LanguageGuessing.idl
+++ b/offapi/com/sun/star/linguistic2/LanguageGuessing.idl
@@ -28,7 +28,7 @@
#ifndef __com_sun_star_linguistic2_LanguageGuessing_idl__
#define __com_sun_star_linguistic2_LanguageGuessing_idl__
-#include XLanguageGuessing.idl
+#include com/sun/star/linguistic2/XLanguageGuessing.idl
module com { module sun { module star { module linguistic2 {
diff --git a/udkapi/com/sun/star/util/logging/Logger.idl b/udkapi/com/sun/star/util/logging/Logger.idl
index 5f02627..72e377a 100644
--- a/udkapi/com/sun/star/util/logging/Logger.idl
+++ b/udkapi/com/sun/star/util/logging/Logger.idl
@@ -29,8 +29,8 @@
#define __com_sun_star_webtop_Logger_idl__
#include com/sun/star/uno/XInterface.idl
-#include XLogger.idl
-#include XLoggerRemote.idl
+#include com/sun/star/util/logging/XLogger.idl
+#include com/sun/star/util/logging/XLoggerRemote.idl
//=
--
1.7.0.4
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
