Re: [dev] Using Boost Library
Hi Regina, AFAIR you can configure using a sytem boost which overrides OOo's boost. HTH, regards, Daniel Regina Henschel wrote: Hello, I want to use the functions tgamma and lgamma from the Boost library, but I need some help. 1. Can you point me to a place, were a function of the Boost library is already used, so that I can see how to do it? 2. The OOo source contains the version boost_1_34_1.tar.gz. But I need the version boost_1_35_0, because tgamma and lgamma not included in the older version. What do I have to do (besides downloading it)? kind regards Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Wiki: C++ Helper Documentations
IIRC (at the time of writing that code, in 2005), OS/2 has had problems getting a newer version of gcc, too. regards, Daniel Thorsten Behrens wrote: Eike Rathke [EMAIL PROTECTED] writes: Given the define kludges needed there for gcc3.3 I wonder whether that is really a helper ;-) Heh! ;-) Yeah, admittedly, doesn't look nice - btw, anybody aware of a platform that still uses 3.3 (apart from panther - and what's the state there?). Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Arbitrary file from within a UNO package
Hello,
IMO (for now until there is no convenient way), you can also go the way
that I have proposed here
http://api.openoffice.org/servlets/ReadMsg?listName=devmsgNo=14040
Assuring a unique jar resource is IMO as hard as assuring a unique
configuration key...
HTH,
-Daniel
Jürgen Schmidt wrote:
Hi Manuel,
first of all, we have already detected this as a missing functionality
and we will provide a simple API for detecting the package root in the
future. But i can't say when it will be available ...
See my comments inline ...
Manuel Odesser wrote:
Hello,
I am building an extension to OOo, using OOBasic and Java. I actually
have two problems.
1) How to open in Java a file bundled in the UNO package ? I followed
instruction from
http://codesnippets.services.openoffice.org/Office/Office.ArbitraryDeploy.snip
(and others). I cannot retrieve a path from a .xcu file for opening. I
have the following code :
private init() throws IOException,Exception {
XComponentContext xContext;
XMultiComponentFactory xServiceManager;
XMultiServiceFactory xProvider;
try {
xContext = com.sun.star.comp.helper.Bootstrap.bootstrap();
} catch (BootstrapException e1) {
e1.printStackTrace();
return false;
}
xServiceManager = xContext.getServiceManager();
Object mxConfigurationProvider =
xServiceManager.createInstanceWithContext(
com.sun.star.configuration.ConfigurationProvider,
xContext);
try {
xProvider = (XMultiServiceFactory)
UnoRuntime.queryInterface(XMultiServiceFactory.class,mxConfigurationProvider);
PropertyValue properties[] = new PropertyValue[1];
PropertyValue property = new PropertyValue();
property.Name = nodepath;
property.Value = my.package;
properties[0] = property;
// create the view
Object xViewRoot =
xProvider.createInstanceWithArguments(com.sun.star.configuration.ConfigurationAccess,properties);
you have to query the new created object to the interface you want to
use, somehting like
XNameAccess xNA =
(XNameAccess)UnoRuntime.queryInterface(XNameAccess.class, xViewRoot );
dataPath = (String)xViewRoot.getByName(myvar);
} catch (Exception e) {
e.printStackTrace();
return false;
}
// get data file
// cut the vnd.sun.star.expand: protocol from the macrofied Url
retrieved from the registry
dataPath = dataPath.replace(vnd.sun.star.expand:,);
Object theExpander;
theExpander =
xContext.getValueByName(/singletons/com.sun.star.util.theMacroExpander);
XMacroExpander oMacroExpander = (XMacroExpander)theExpander;
you can't simply cast this object. getValueByName returns an Any
which of course is mapped in Java to Object. You have either to use the
AnyConverter or if you need a specific interface use again
2queryInterface which allows Any object directly.
dataPath = oMacroExpander.expandMacros(dataPath);
BufferedReader buffer = new BufferedReader(new
FileReader(dataPath));
}
* problem 1 : xViewRoot is viewed as an Object, and therefore has no
getByName() method. And I can't cast to
com.sun.star.configuration.ConfigurationAccess because Eclipse couldn't
locate the appropriate file.
* problem 2 : An exception is throw at runtime during the cast of
variable theExpander.
* problem 3 : what is the typical .xcu file that could contain
%origin%/mypath/myfile.dat ?
Currently you have to define your own package specific configuration
schema and you have to provide an appropriate xcu file depending on this
schema together with all other files in your package. In a second step
you can use the configuration API to work with your own configuration
and the MacroExpander to get a valid Url.
Sorry that it is so complicate but we are working on improvements.
Juergen
2) I have a addons.xcu that begins with :
oor:component-data
xmlns:oor=http://solstage2.sfo.collab.net/2001/registry;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
oor:name=Addons
oor:package=org.openoffice.Office
node oor:name=AddonUI
node oor:name=AddonMenu
node
oor:name=mypackage.myaddon
oor:op=replace
Is mypackage.myaddon a suitable/valid name ? Should it begin with
org.openoffice or something else ?
Sorry for this long email, and thank very much in advance for your
answers !
--
Manuel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] x86 osl/interlck.h performance
I also found from timing tests using hand-optimised assembler that calls
to the Win32 API Interlocked routines appeared to be optimised when the
code is compiled by MSVC, but not GCC (say). It was as though MSVC was
emitting optimised assembler on the fly instead of calling the routines
in Kernel32.dll. My timings showed that the standard Interlocked routine
calls compiled with MSVC were as fast or faster than my inlined
assembler without the LOCK prefix. The interlocked routines are used as
the basis for the mutex operations in pthreads-win32, and using the
assembler versions, I was able to cut the time for some of the pthreads-
win32 test applications involving saturated POSIX reader-writer lock
calls to nearly 1/3 for the gcc compiled versions, and match the times
produced by the MSVC compiled code.
Now that's interesting! Did you disassemble what MSVC emits instead of
calling the interlocked routines. How do they achieve atomic operations
without the lock prefix to xadd, xchg or cmpxchg instructions?
However, compiling on my Pentium-M lets VS8 always take the kernel32
routines (tried all /O? options, taking decls from winbase.h): no
intrinsics [1].
Though including the intrinsic versions directly works, the code is inlined:
#include intrin.h
void foo(long * p)
{
_InterlockedIncrement(p);
}
[d:\]cl -c /Ox t.cxx ^ dumpbin /DISASM t.obj
[...]
0004: B9 01 00 00 00 mov ecx,1
0009: F0 0F C1 08lock xadd dword ptr [eax],ecx
regards,
-Daniel
[1] http://msdn2.microsoft.com/en-us/library/2ddez55b(VS.80).aspx
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] libgcc3_urp.so
Hello Ognen, strace of the process shows that a library libgcc3_urp.so is looked up but it does not exist on the system. Even stranger, google-ing for it produces absolutely no hits. Can anyone shed any light on this? The box is a Fedora Core 4 if that makes a difference... It is ok that libgcc3_urp.so is looked up (once). Background: UNO tries to load a directly matching bridge first (bridging in between gcc3 to urp). If this bridge is not available, a bridge is build up connecting two bridges to (binary) uno, i.e. libgcc3_uno.so and liburp_uno.so: gcc3 - uno - urp HTH, -Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal: rtl::LeakGuard
Hello, talking offline here in Hamburg, we agreed that it makes sense to add such a class. Special tests with external tools (valgrind, BoundsChecker) are valuable, but may not cover a problematic program path leading to leaks, because those tests are most often run by developers. Using the proposed class gives easy indication that something goes wrong in every nonpro build, like OSL_ASSERTs do. We agreed to shift the existing checking/statistics facilities from tools into that class (which is future work), so there will be only one consolidated API. For the moment - the class will be an unpublished API in osl/diagnose.hxx, that may change in the future - the name will change to DebugBase (reflecting that it (potentially) does more than just leak checking, e.g. storing construction stack traces, counting statistics) Did I forget anything? regards, -Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal: rtl::LeakGuard
Hello Malte, I like leak detection, but I think inheritance is not so useful here, because you can't simply add leak detection to a class 'on demand', without compiling all following modules. There is no need to recompile derived classes/modules, because the LeakGuard-ed class references only static data and has no vtable. Nevertheless, IMO leak detection has to be thoroughly considered during programming, same as you add OSL_ASSERTs to your code, so there ought to be little need for on-demand leak detection. We already have some leak detection in tools/debug.hxx: DBG_CTOR and DBG_DTOR. Together with DBG_CHECKTHIS, you can also use it to check if your object is still valid. Advantage: No inheritance (Small) Disadvantage: Manually put DBG_CTOR/DTOR in all ctors and dtors. I really don't like macros, and IMO it is much more elegant to just inherit the LeakGuard feature without thinking about constructors and destructors. So maybe you would like to extend the things we already have in tools... This would not solve the need for lower level modules, e.g. UDK modules. regards, -Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal: ServiceDecl
One nit: since the automatic implementation name derivation looks kind of fragile (and most of the time, I _do_ declare my service implementations in anonymous namespaces) - how about disabling that feature by default? I have the impression that not much of OOo development outside Sun takes place on Windows, and specifying one (more) string at the constructor is really not that much overhead... Yes, the current implementation disallows the use of anonymous namespaces (at least on Windows, the dll cannot be registered). I agree, it is really not much work to specify an implementation name, but it would be nice to get rid of it. IMO the current (though not specified) rule inserting a comp. into the service name to make an implementation name, e.g. org.openoffice.package.MyService = org.openoffice.comp.package.MyService is even more fragile. I think using a named namespace (instead of an anonymous) is not really overhead, and, with the prepended library name, the implementation name is unique: - double class definitions in the same library leads to link error - use of anonymous namespace for class_ leads to registration error Of course, the safe solution would be a globally unique identifier (GUID), but much more overhead. regards, -Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal: ServiceDecl
Hello Niklas, namespace sdecl = comphelper::service_decl; sdecl::ServiceDecl const myDecl( sdecl::class_MyImpl(), org.openoffice.MyService, [optional my.implementation.name] ); If used as a global object, with a constructor that is executed when the DLL is loaded, that won't help with start-up performance. IMO it doesn't matter whether you create that data (mostly the implementation name) at the point of loading the library or slightly later when the UNO service needs to be instantiated. But I agree that those ctors are executed even though not all services may be needed from that library, e.g. at the extreme if only one of 100 is used. Thus, it makes sense to optimize the current ctors, so they only save the passed char pointers, late-initializing OUString/Sequence objects when needed. For the case of multiple supported services we could e.g. use a separated list of service names like Service1;Service2; All in all, I assume runtime performance is hardly affected then. regards, -Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] proposal: ServiceDecl
Hello,
I'd like to present/discuss a recent helper I have developed which IMO
simplifies the implementation of UNO services in C++ a lot.
Using the following (what I call) service declaration, the developer can
concentrate on implementing her service's interfaces, e.g.
class MyImpl : cppu::WeakImplHelper2XInterface1, XInterface2 {...};
There is no need to implement lang::XServiceInfo nor
lang::XInitialization (if the service expects arguments for creation).
Next, one just has to declare the above class defining a service
declaration object:
namespace sdecl = comphelper::service_decl;
sdecl::ServiceDecl const myDecl(
sdecl::class_MyImpl(),
org.openoffice.MyService,
[optional my.implementation.name] );
The ServiceDecl ctor expects as
1st parameter: a comphelper::service_decl::class_ object as first
parameter (which I further explain shortly)
2nd parameter: a single name or a uno::Sequencertl::OUString stating
the supported service names
3rd parameter (optional): an implementation name; if this has been
omitted, the implementation name will be generated out of MyImpl'S
type_info (which I will explain shortly).
The class_ object states the user's implementation class, which by
default is required to define a constructor taking a
uno::Referenceuno::XComponentContext
as its sole argument. If the user requires service arguments for
construction, she can customize the class_ object, using
sdecl::class_MyImpl, sdecl::with_argstrue ()
In this case, the user's implementation class is required to define a
constuctor taking
uno::Sequenceuno::Any,
uno::ReferenceXComponentContext
If the user needs to execute special post processing code, e.g. for
registering the newly created object as a listener, then she can specify
a function/functor, too:
sdecl::class_MyImpl, ...(postProcessing)
That functor needs to be of the following form, e.g.
uno::Referenceuno::XInterface postProcessing( MyClass * p );
and gets the _yet unacquired_ pointer.
If the implementation name ought to be generated, then the mangled C++
name including the user's class is taken into account as well as the
library name, e.g. a generated name may look like:
deployment680mi.uno.dll;[EMAIL PROTECTED]@dp_manager@@
(MSVC, using type_info::raw_name())
deployment680li.uno.so;N10dp_manager7factory25PackageManagerFactoryImplE
(gcc 3.4.1, using type_info::name())
There is a flaw when the user uses an anonymous namespace for the
implementation class:
- At least on Windows there is the possibility that the generated
implementation name is not unique (e.g. same anonymous class name in two
different compilation units within same dll).
- g++ mangles the whole compilation path into the anonymous symbol (+
time stamp etc.). This will avoid the possibility to just quickly
compile and link a library with debug and exchange without
re-registering it, which I fear leads to subtle confusion.
IMO, sad but true, using a anonymous namespace is a bad idea here, so I
currently disallow this leading to a runtime error when the library is
loaded, stating these problems (currently on Windows only; easy to
detect). Implementation classes have to be declared in a _named_
namespace (if any).
When it comes to exporting the necessary component_xxx() functions,
there are new helper functions that can deal with a variable number of
ServiceDecl objects:
extern C {
void SAL_CALL component_getImplementationEnvironment(
const sal_Char ** ppEnvTypeName, uno_Environment ** )
{
*ppEnvTypeName = CPPU_CURRENT_LANGUAGE_BINDING_NAME;
}
sal_Bool SAL_CALL component_writeInfo(
lang::XMultiServiceFactory * pServiceManager,
registry::XRegistryKey * pRegistryKey )
{
return component_writeInfoHelper(
pServiceManager, pRegistryKey, myDecl, myDecl2, ... );
}
void * SAL_CALL component_getFactory(
sal_Char const * pImplName,
lang::XMultiServiceFactory * pServiceManager,
registry::XRegistryKey * pRegistryKey )
{
return component_getFactoryHelper(
pImplName, pServiceManager, pRegistryKey, myDecl, myDecl2, ...);
}
} // extern C
By default, the component_xxxHelper() functions can cope with up to 8
declarations (can be increased using
COMPHELPER_SERVICEHELPER_COMPONENT_HELPER_MAX_ARGS before including
comphelper/servicedecl.hxx).
You can have a look at the implementation on cws dbo510 (tag
cws_src680_dbo510):
comphelper/inc/comphelper/servicedecl.hxx
comphelper/inc/comphelper/makesequence.hxx
comphelper/source/misc/servicedecl.cxx
For testing purposes, I have adopted the deployment API implementation
(module desktop) which comes with quite a lot services.
So what do you think? Comments, please.
regards,
-Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] warnings01: -Wnon-virtual-dtor
On such compilers, this warning will occur for each idlc-generated UNO header (com/sun/star/uno/XInterface.hpp etc.). For reasons of compatibility, it is not an option to change those idlc-generated headers and add a virtual destructor to them. Should be sufficient using this pragma only in interface header files generated by cppumaker. Thus, we can either switch off -Wnon-virtual-dtor globally, or switch off *all* warnings from within idlc-generated headers (#pragma GCC system_header). The second option is probably preferable, as -Wnon-virtual-dtor might point to real issues in other places of the code base, and it is unlikely that there would be other warnings from any idlc-generated header that we would thus suppress---the idlc-generated headers are pretty boiler-plate. +1, switching off globally is really no good option. -Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] [HOTD] comphelper::sequenceToContainer friends
Hello,
template typename DstType, typename SrcType
::com::sun::star::uno::Sequence DstType arrayToSequence( const
SrcType* i_pArray, sal_Int32 nNum )
{
::com::sun::star::uno::Sequence DstType result( nNum );
::std::copy( i_pArray, i_pArray+nNum, result.getArray() );
return result;
}
If DstType and SrcType refer to the same type (which is often the case),
using one of Sequence's ctors is faster, i.e.
::com::sun::star::uno::SequenceDstType seq( pArray, nElements );
Adding a special
template typename T
inline ::com::sun::star::uno::SequenceT arrayToSequence(
T const* p, sal_Int32 n )
{
return ::com::sun::star::uno::SequenceT(p, n);
}
would most probably break existing code which has explicitly specified
DstType (= leads to ambiguity when DstType equals SrcType). So I
recommend to use that Sequence ctor directly whenever possible.
template typename DstType, typename SrcType
::com::sun::star::uno::Sequence DstType containerToSequence( const
SrcType i_Container )
{
::com::sun::star::uno::Sequence DstType result( i_Container.size()
);
::std::copy( i_Container.begin(), i_Container.end(),
result.getArray() );
return result;
}
The same optimization applies when copying from a std::vector; can
seamlessly be overloaded by adding
template typename T
inline ::com::sun::star::uno::SequenceT containerToSequence(
::std::vectorT const v )
{
return ::com::sun::star::uno::SequenceT( v[0], v.size() );
}
(No need to explicitly state the element type.)
I will add the latter function to comphelper/sequence.hxx if nobody
(incl. any compiler) complains.
regards,
-Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [c++]openoffice exception handling
Hello aditya kumar pandey,
Modified bit of my code:
OUString oStr = OUString::createFromAscii(foo.Counter);
try
{
throw (com::sun::star::uno::Exception());
//also tried
//throw (com::sun::star::uno::Exception(oStr,xMgr));
}
catch (com::sun::star::uno::Exception e)
{
}
catch (...)
{}
Looks strange, because there is still no inter-language part involved
(UNO bridging). Does the (unmodified) counter example compile and run
successfully?
Seems that even simplest exception handling does not work on your
compiler. Have you tried to write a simple program (without linking
against any SDK libraries) throwing your own exception type, e.g.
#include stdio.h
struct MyExc {};
int main()
{
try {
throw MyExc();
}
catch (MyExc ) {
printf(caught\n);
}
return 0;
}
-Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] [c++]openoffice exception handling
Hello Eike, *
Hi Daniel,
On Thu, Aug 04, 2005 at 18:00:21 +0200, Daniel Bölzle wrote:
additional tip: always catch by reference (Exception ), saving an extra
copy construction.
Not only saving copy construction, but also preventing slicing off
derived classes in case only a base class is caught and the exception is
re-thrown. Also matters if the exception is modified and re-thrown, the
modifications would be lost.
Yes. Also worth mentioning in this context is that (most often) a
temporary is constructed and thrown (most often, because this
temporary may be eliminated: standard 15.1.5).
This may become a trap, e.g. even catching by reference in the following
sample does not do the intended:
MyExc e;
try {
throw e;
}
catch (MyExc r) {
r.modify();
}
// e is left _unmodified_!
-Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] re: difficulty with package to add menu to Calc
I am starting to understand where my confusion is now. I looked at the ProtocolHandler example, and there is no idl. So, I guess I have to manually register my protocolhandler, or the java classes that it calls. How do I do that when the person installs the plugin, as I don't want the users to have to do much to use the plugin. No, just specify proper manifest.xml entries and unopkg/PackageManager UI will install you add-on zip (.uno.pkg) the right way. Or, do I need to create an idl for the java classes that the protocolhandler will call, and then go through the four steps to have a java class from that, and then implement that interface? I don't understand. You mentioned in some previous mails that your add-on works when you just zip all files up and install that zip with pkgchk. pkgchk more or less just tries to install everything found in a zip, even if it makes no sense, e.g. a jaxrpc.jar will be detected as a UNO jar typelibrary. So if you want to correct that, you can use the new package bundle (since 2.0, extension .uno.pkg) format which lets you specify detailed media types for each particle of your add-on bundle. All other files are ignored. HTH, -Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] re: difficulty with package to add menu to Calc
Hello James, Daniel Boelzle wrote: Your media types are wrong. I assume you are not only deploying jar type library files... :) So specify media types for your configuration data files (xcu) = application/vnd.sun.star.configuration-data, your jar UNO components = application/vnd.sun.star.uno-component;type=Java etc. Note: don't specify dependent jar files (like your jaxrpc in the manifest) as UNO typelibrary, because those are no typelibraries. List those dependent jars in your UNO component's manifest.mf (Class-Path line, see manifest.mf spec of your JDK). Finally, the UNO package deployment scheme is expained in the developer's guide (see your SDK). I had fixed the media-types for my.xcu files, as I realized I was incorrect there. I am curious about application/vnd.sun.star.uno-typelibrary;type=Java though. I have one jar file that is created from classes that came from my .idl file. which ought to have media-type application/vnd.sun.star.uno-typelibrary;type=Java (already correct) I have two other jar files that use classes in the OO SDK, but I wrote those, such as the ProtocolHandler. How do I put those in the manifest.xml file? when that jar file(s) are implement as a UNO component which needs to be registered, then give them media-type application/vnd.sun.star.uno-component;type=Java HTH, -Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] C++: Bad interdependencies between certain types and templates
Hello, http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#488), [...] The morale? Well, I am not sure. Stop using C++, as it is not a language you want to mess around with; bite the bullet and avoid unnamed and local enums; maybe it would also have been more clever to hide the Any's operator == template function in namespace com::sun::star::uno... Argh. What about lobbying the gcc people to consider option 2 or 3 from the referenced C++ language issue? I mean, the whole point of SFINAE is to have templates fail gracefully in cases where actual instantiations are not used (I know, the case in point is slightly different in nature, though not in spirit). Since member template functions are supported by all target compilers now, this can hopefully be solved by shifting all binary operators with left side Any to class Any? regards, --Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
