Re: [udk-dev] UNO URE
On 10/26/10 20:52, Nelson, Robert wrote: I would like to download both the latest and version 2.3.0 of the UNO URE. I cannot either the latest version or 2.3.0 on http://ownload.openoffice.org. I can find 0.x and 1.x versions though. As OOo is packaged up as a bundle of platform-specific packages (rpm, deb, etc.) since OOo 3.0, and one of them is the URE package, we no longer offer an independent download of URE itself. Just download the complete OOo and pick the URE package from there. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org For additional commands, e-mail: dev-h...@udk.openoffice.org
[udk-dev] Re: [dev]setting URE_BOOTSTRAP
On 09/18/10 01:33, Soohong Min wrote:
I am trying to set URE_BOOTSTRAP as follows:
export
URE_BOOTSTRA=vnd.sun.star.pathname:/home/openoffice3.2/program/fundamentalrc
Missing a P? The OOo python start script at
http://hg.services.openoffice.org/DEV300/file/2ebd15d9e8a6/pyuno/zipcore/python.sh#l56
only sets URE_BOOTSTRAP if it is unset.
BTW,
After I will check my URE_BOOTSTRAP with python scripts
print (os.environ['URE_BOOTSTRAP'])
It indicates that
vnd.sun.star.pathname:${exec_prefix}/lib/ooo-3.2/program/fundamentalrc
I don't know why this is happening.
My issue is that I got error message related to LoadComponentFromUrl
Error. So to solve this problem, I tried to set URE_BOOTSTRAP but I
cound not fix it.
There should never be a need to set URE_BOOTSTRAP manually -- a
correctly set up OOo will take care of that itself.
-Stephan
-
To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org
For additional commands, e-mail: dev-h...@udk.openoffice.org
Re: [udk-dev] Question for Python-UNO bridge on Mac OSX
On 09/09/10 15:50, basZero wrote: Hi, is this mailing list still alive? Yes. (However, when you are not subscribed, see http://udk.openoffice.org/servlets/ProjectMailingListList, your mails need to be manually moderated, causing work and leading to potentially lost mails.) -Stephan - To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org For additional commands, e-mail: dev-h...@udk.openoffice.org
Re: [udk-dev] Mirroring ,v-files and CVSROOT
On 04/22/10 19:53, Powered Milkman wrote: I've got a question according to the CVSROOT on the CVS-Server. Is it possible to get all the ,v-files and CVSROOT on my local PC? The d...@tools.openoffice.org mailing list is more appropriate for this kind of question. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org For additional commands, e-mail: dev-h...@udk.openoffice.org
Re: [udk-dev] [Basic]Initialisation of a web service
On 01/28/10 11:31, Philippe Denis wrote: Last question : if I want to modify the web service package. How can I do? Actualy, I'm trying to modify the .jar that is inside of this file : http://udk.openoffice.org/java/examples/wsproxy/WebServiceProxy.zip But after, It's impossible to install this package in OO. The source can only be accessed via CVS (it has not been migrated to HG, unlike the still active parts of the old OOo CVS repository; also see http://wiki.services.openoffice.org/wiki/CVS), module udk/soap. I never really looked at the code, but it looks like udk/soap/proxy/build.xml is an ant file to build the stuff (requiring that Environment variables ODK_HOME and OFFICE_PROGRAM_PATH *must* exist, so you would have to set at least those before trying it out; I can imagine that there are further problems, as the structure of an OOo installation set has changed significantly over the years). If you get stuck anywhere, feel free to ask. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org For additional commands, e-mail: dev-h...@udk.openoffice.org
Re: [udk-dev] [Basic]Initialisation of a web service
On 01/27/10 10:20, Philippe Denis wrote: I'm trying to use a web service with OOo Basic. However when I try to initialize this web service, I receive one error. Basicly, I test with this code : Sub Main proxyFac = createUNOService(com.sun.star.webservices.proxy.ProxyFactory) 'Getting the UNO service proxyFac = createUNOService(com.sun.star.webservices.proxy.ProxyFactory) ' Initializing of the ProxyFactory by providing the WSDL: proxyFac.initialize(Array(http://www.flash-db.com/services/ws/companyInfo.wsdl;)) End Sub The line 'proxyFac.initialize(...)' returns an error. I'v taken a picture of this error : http://user.services.openoffice.org/fr/forum/download/file.php?id=12779mode=view However, with this WSDL (http://www.rightactionscript.com/states/webservice/StatesService.php?wsdl), the initialisation works. To install the web service and the JWSDP, I followed this tutorial : http://udk.openoffice.org/java/examples/wsproxy/component_description.html#ToCDownload and I'm sure it works. I dont't understand why It doesn't work in few case. Maybe, the error is provide by the WSDL File Itself. Looks like the code at http://udk.openoffice.org/source/browse/udk/soap/proxy/src/com/sun/star/comp/webservice/unoproxy/WSDLDocumentHandler.java?rev=1.12view=markup cannot cope with certain kind of input (definitionsMap is set at l. 124 for a startElement with qName==definitions and is used---and obviously still null in your case---at l. 244 for a startElement with sName==MESSAGE; maybe the sequence of startElements in your case is not as anticipated by the author of the code). That code lies unmaintained for a very long time now. I guess you are on your own debugging it... -Stephan - To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org For additional commands, e-mail: dev-h...@udk.openoffice.org
Re: [udk-dev] [Basic]Initialisation of a web service
On 01/27/10 11:11, Philippe Denis wrote: After some researchs, I think my code doesn't accept the WSDL 2. I explain : the WSDL working are from the version 1 of WSDL and the others that don't wrok are from the version 2. If I understand, this problem is from the UDK projet or no? The code is archived in the (old CVS) repository of the UDK project, right. But there is nobody (to my knowledge) who maintains that code. (The code mainly came out of some internship project several years ago.) If you want to improve it---go ahead! :) -Stephan - To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org For additional commands, e-mail: dev-h...@udk.openoffice.org
Re: [udk-dev] headless package closes connection - was Re: [udk-dev] (tid=3) Unexpected connection closure
On 11/19/09 21:59, Lukasz Szybalski wrote: On Thu, Nov 19, 2009 at 1:26 AM, Kay Ramme kay.ra...@sun.com wrote: Hi Lukasz, could you give a brief overview over your system, the OS, the arch and the OOo version etc.? That would help debugging this. You find the detailed OOo version in the about dialog. The upgraded version is : 3.1.1.1-1bpo50+1 sat sept 2009 The memory problem is again in the headless portion. That is probably http://qa.openoffice.org/issues/show_bug.cgi?id=105191. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org For additional commands, e-mail: dev-h...@udk.openoffice.org
Re: [udk-dev] Question about weak reference list inside java bridge.
On 11/23/09 07:58, Huaidong Qiu wrote:
Hi all,
We got a problem like this, one of the L2 entry list keep growing consume
too much memory.
module jurt
package com.sun.star.lib.uno.
environments.java;
the cleanUp member function of class Registry.
// must only be called while synchronized on map:
private void cleanUp() {
for (;;) {
Level2Entry l2 = (Level2Entry) queue.poll();
if (l2 == null) {
break;
}
// It is possible that a Level2Entry e1 for the OID/type
pair
// (o,t) becomes weakly reachable, then another Level2Entry
e2
// is registered for the same pair (o,t) (a new Level2Entry
is
// created since now e1.get() == null), and only then e1 is
// enqueued. To not erroneously remove the new e2 in that
case,
// check whether the map still contains e1:
String oid = l2.getOid();
Level1Entry l1 = getLevel1Entry(oid);
if (l1 != null l1.get(l2.getType()) == l2) {
removeLevel2Entry(oid, l1, l2);
}
}
}
All those weak reference Level2Entry entries are invalid, the condition
(l1.get(l2.getType()) == l2) keeps cleanUp function from removing them from
the list.
I think if this
// It is possible that a Level2Entry e1 for the OID/type
pair
// (o,t) becomes weakly reachable, then another Level2Entry
e2
// is registered for the same pair (o,t) (a new Level2Entry
is
// created since now e1.get() == null), and only then e1 is
// enqueued.
happened once then there is no way the condition (l1.get(l2.getType()) ==
l2) can be true again, because get(l2.getType()) always return the first
element in the list, but queue.poll() return the newly released weak
reference which can not be the first one in the list.
I fail to see a flaw in the current algorithm. In the simplest case,
consider a Level1Entry L that has just one Level2Entry E (for some
object O, OID D, type T) in its list. Suppose o1 has become unreachable
and cleanUp is called: l2 will be bound to E; oid will be bound to D; l1
will be bound to L; l2.getType() returns T; l1.get(l2.getType()) returns
E, so removeLevel2Entry will be called and will indeed remove E from L's
list (and will actually also remove L from the map of Level1Entries).
If weak reference list cleanup mechanism is correct, could please give some
possible reasons could cause the growing problem of L2 entry list.
You mean, you observe a specific instance of Level1Entry whose list of
Level2Entries keeps growing without bound? That sounds strange. First,
all entries in the list should be for different UNO types supported by
the respective UNO object, so that should bound the length of the list
(no UNO object probably supports more than a few dozen different UNO
types). Second, the only way to have more entries in the list would be
to have entries referencing different reachable Java objects which would
nevertheless all have the same UNO OID. That would sound like a bug
somewhere.
Maybe you can add debug code to print, for each Level2Entry E in the
list of the given problematic Level1Entry, the following:
- E.toString()
- E.getOid()
- E.getType()
- E.get()
to get an idea what that growing list looks like.
-Stephan
-
To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org
For additional commands, e-mail: dev-h...@udk.openoffice.org
Re: [udk-dev] Question about weak reference list inside java bridge.
Yes, thanks. I think now I get it. The code in cleanUp mistakenly
thinks that Level1Entry.get is backed by a map (where there can be at
most one entry for a given key) while in fact it is backed by a list
(acting like a multi-map, allowing multiple entries for a given key).
I will see how best to fix that tomorrow. If you like, you can file an
issue (otherwise, I will file one myself).
-Stephan
On 11/23/09 18:15, Huaidong Qiu wrote:
This is a bad list. I print out
Type,
oid,
o.toString()
The first one is a unreachable object's weak reference, which causes the
growth of list.(not all of them are unreachable, my mistake before)
list start +
list size: 6
Type[com.sun.star.uno.XCurrentContext]
287d368;msci[0];e64524147b554dde941e6f95d22dc0
null
Type[com.sun.star.uno.XCurrentContext]
287d368;msci[0];e64524147b554dde941e6f95d22dc0
[Proxy:329388962,287d368;msci[0];e64524147b554dde941e6f95d22dc0,Type[com.sun.star.uno.XCurrentContext]]
Type[com.sun.star.uno.XCurrentContext]
287d368;msci[0];e64524147b554dde941e6f95d22dc0
[Proxy:329388962,287d368;msci[0];e64524147b554dde941e6f95d22dc0,Type[com.sun.star.uno.XCurrentContext]]
Type[com.sun.star.uno.XCurrentContext]
287d368;msci[0];e64524147b554dde941e6f95d22dc0
[Proxy:329388962,287d368;msci[0];e64524147b554dde941e6f95d22dc0,Type[com.sun.star.uno.XCurrentContext]]
Type[com.sun.star.uno.XCurrentContext]
287d368;msci[0];e64524147b554dde941e6f95d22dc0
[Proxy:329388962,287d368;msci[0];e64524147b554dde941e6f95d22dc0,Type[com.sun.star.uno.XCurrentContext]]
Type[com.sun.star.uno.XCurrentContext]
287d368;msci[0];e64524147b554dde941e6f95d22dc0
[Proxy:329388962,287d368;msci[0];e64524147b554dde941e6f95d22dc0,Type[com.sun.star.uno.XCurrentContext]]
list end +
On Mon, Nov 23, 2009 at 9:32 PM, Huaidong Qiu qiuhuaid...@gmail.com wrote:
Thanks Stephan,
I already print out the list's contents, the elements's oid and type are
the same,
but the objects are unreachable.
Same oid because those weak references belong to same L1 entry, no problem
here.
Let's consider a Level1Entry contains two Level2Entry: l2_1, l2_2.
if l2_1, l2_2 have same type, l1.get(l2.getType()) will return l2_1
because l1.get will return the first element match the type.
// must only be called while synchronized on map:
public Level2Entry get(Type type) {
for (Iterator i = list.iterator(); i.hasNext();) {
Level2Entry l2 = (Level2Entry) i.next();
* if (l2.getType().equals(type)) {*
return l2;
}
}
return null;
}
but if when cleanUp was called, the unreachable object is l2_2, the
condition
(l1.get(l2.getType()) == l2) in cleanUp function will not be met.
I think this is the problem we have, you can see the list will keep growing
after this.
-Huai Dong
On Mon, Nov 23, 2009 at 8:15 PM, Stephan Bergmann
stephan.bergm...@sun.com wrote:
On 11/23/09 07:58, Huaidong Qiu wrote:
Hi all,
We got a problem like this, one of the L2 entry list keep growing consume
too much memory.
module jurt
package com.sun.star.lib.uno.
environments.java;
the cleanUp member function of class Registry.
// must only be called while synchronized on map:
private void cleanUp() {
for (;;) {
Level2Entry l2 = (Level2Entry) queue.poll();
if (l2 == null) {
break;
}
// It is possible that a Level2Entry e1 for the OID/type
pair
// (o,t) becomes weakly reachable, then another
Level2Entry
e2
// is registered for the same pair (o,t) (a new
Level2Entry
is
// created since now e1.get() == null), and only then e1
is
// enqueued. To not erroneously remove the new e2 in that
case,
// check whether the map still contains e1:
String oid = l2.getOid();
Level1Entry l1 = getLevel1Entry(oid);
if (l1 != null l1.get(l2.getType()) == l2) {
removeLevel2Entry(oid, l1, l2);
}
}
}
All those weak reference Level2Entry entries are invalid, the condition
(l1.get(l2.getType()) == l2) keeps cleanUp function from removing them
from
the list.
I think if this
// It is possible that a Level2Entry e1 for the OID/type
pair
// (o,t) becomes weakly reachable, then another
Level2Entry
e2
// is registered for the same pair (o,t) (a new
Level2Entry
is
// created since now e1.get() == null), and only then e1
is
// enqueued.
happened once then there is no way the condition (l1.get(l2.getType()) ==
l2) can be true again, because get(l2.getType()) always return the first
element in the list, but queue.poll() return the newly released weak
reference which can not be the first one in the list.
I fail to see a flaw
Re: [udk-dev] headless package closes connection - was Re: [udk-dev] (tid=3) Unexpected connection closure
On 11/12/09 18:49, Lukasz Szybalski wrote: I did not see my application fail or get disconnected in non-headless mode. I do see it failing in headless. [...] Are there any differences in headless vs non-headless? Is there a different mailing list I should be asking these questions? (headless mailing list?) I asked Philipp Lohmann from the VCL team (relevant list would be d...@gsl.openoffice.org) if he knows about any stability issues with headless mode, but he had nothing to offer. If the cause for the unexpected connection closure is a crash of OOo, I guess you will need to attach a debugger to OOo so we can find out more. aptitude show openoffice.org-headless Package: openoffice.org-headless New: yes State: installed Automatically installed: no Version: 1:2.4.1+dfsg-1 Priority: optional Section: misc Uncompressed Size: 2347k Depends: openoffice.org-core (= 1:2.4.1+dfsg-1), libc6 (= 2.7-1), libgcc1 (= 1:4.1.1), libstdc++6 (= 4.1.1), libstlport4.6ldbl Description: Headless VCL plugin for OpenOffice.org OpenOffice.org is a full-featured office productivity suite that provides a near drop-in replacement for Microsoft(R) Office. maybe I should try go-oo.org? Reportedly, go-oo used a different implementation of headless than vanilla OOo in the past, but probably have converged to the vanilla one by now. (But the above output suggests that you still use OOo 2.4.1, which is really old. Use OOo 3.1.1 or snapshots of the forthcoming OOo 3.2 instead!) In any event, if you are using OOo based on the go-oo fork, it is probably best to ask there first. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org For additional commands, e-mail: dev-h...@udk.openoffice.org
Re: [udk-dev] PyUNO : Inserting a User field
On 10/23/09 11:47, Etienne Gaudrain wrote: After a few more attempts, its seems that: xMasterPropSet.setPropertyValue(Content, Toto) works perfectly fine. So this is the use of Name as a property that is not allowed in setPropertyValue. Each UNO object implementing XPropertySet has its own rules what kinds of property names (and corresponding values) it supports. It might well be that a com.sun.star.text.FieldMaster.User does not support a Name property, but I do not know (offapi/com/sun/star/text/fieldmaster/User.idl says that it inherits from offapi/com/sun/star/text/TextFieldMaster.idl, which only has an optional Name property, so that might give a clue). d...@api.openoffice.org would be the right mailing list for such questions. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org For additional commands, e-mail: dev-h...@udk.openoffice.org
Re: [udk-dev] Building PUNO On OOo 3.x
On 05/28/09 16:21, Adam Tauno Williams wrote: On Thu, 2009-05-28 at 09:25 +0200, Stephan Bergmann wrote: On 05/27/09 15:46, Adam Tauno Williams wrote: On Fri, 2009-05-22 at 10:13 +0200, Stephan Bergmann wrote: On 05/20/09 20:20, Adam Tauno Williams wrote: On one of our webservers with use PUNO (the PHP UNO module http://www.wstech2.net/index.php?do=puno_install) to communicate with OOo running as a service. In that case it is openSUSE 10.3 with OpenOffice_org-2.3.0.1.2-10.5. The module builds an works perfectly. Now we need to deploy on openSUSE 11.1 with OpenOffice_org-3.0.1.3-3.1. But unforunately the module fails to build since [as I interpret it) the UNO API has changed: OK: tar xf puno-0.6.tar.gz Where did you get that tar file from? I do not know what it is. http://sourceforge.net/project/showfiles.php?group_id=197229 I see. OK: cd puno-0.6 OK: /usr/lib/ooo3/basis3.0/sdk/setsdkenv_unix OK: phpize OK: ./configure --with-puno=/usr/lib/ooo3/basis3.0/sdk OK: make cppumaker FAILS: make install (or just make) /usr/lib/ooo3/basis3.0/sdk/include/cppu/unotype.hxx: In static member function 'static const com::sun::star::uno::Type cppu::UnoType template-parameter-1-1 ::get() [with T = int]': /usr/lib/ooo3/basis3.0/sdk/include/cppu/unotype.hxx:293: instantiated from 'const com::sun::star::uno::Type cppu::getTypeFavourUnsigned(const T*) [with T = int]' /usr/lib/ooo3/basis3.0/sdk/include/com/sun/star/uno/Any.hxx:205: instantiated from 'void com::sun::star::uno::operator=(com::sun::star::uno::Any, const C) [with C = int]' /root/puno-0.6/funcs.cpp:232: instantiated from here puno-0.6/funcs.cpp:232 is arguments[0]=xComponentLoader; and xComponentLoader is declared as Reference XComponentLoader xComponentLoader( at l. 184. However, that the complaint is about com::sun::star::uno::operator=(com::sun::star::uno::Any, const C) [with C = int] would imply that at l. 232 the compiler assumes that xComponentLoader is of type int, not of type com::sun::star::uno::Referencecom::sun::star::frame::XComponentLoader. Something seems to go terribly wrong here. What is the exact gcc call that causes the error, and is the given error output the complete output of that gcc call, or just the tail? I have published the output of the entire process: /usr/lib/ooo3/basis3.0/sdk/setsdkenv_unix setsdkenv_unix.out https://www.mormail.com/snips/OGo12939740/setsdkenv_unix.out phpize phpize.out https://www.mormail.com/snips/OGo12939740/phpize.out ./configure --with-puno=/usr/lib/ooo3/basis3.0/sdk configure.out https://www.mormail.com/snips/OGo12939740/configure.out https://www.mormail.com/snips/OGo12939740/config.log.out (the resulting config.log file) make --debug=i cppumaker make.cppumaker.out https://www.mormail.com/snips/OGo12939740/make.cppumaker.out make --debug=i make.out https://www.mormail.com/snips/OGo12939740/make.out As I expected, there are earlier errors about missing headers, like In file included from /root/puno-0.6/puno.cpp:19: /root/puno-0.6/php_puno.h:41:53: error: com/sun/star/registry/XSimpleRegistry.hpp: No such file or directory Those headers (declaring the C++ bindings for the OOo UNO types) are, AFAIK, not shipped with the SDK, but shall presumably be built by the make cppumaker step, whose output Prerequisite `/root/puno-0.6/modules/types.rdb' of target `cppumaker' does not exist. hints at the alleged root problem: I guess that one of the earlier steps shall copy a types.rdb from the OOo installation to puno-0.6/modules/types.rdb. With OOo 2, there was a single types.rdb within the OOo installation, at opt/openoffice.org2/program/types.rdb. With OOo 3, this has changed, and the original types.rdb has been split into opt/openoffice.org/ure/misc/types.rdb and opt/openoffice.org/basis3.X/program/offapi.rdb (where the X is the OOo 3.X minor version number). (These files are considered internal artifacts of OOo, so no external mechanism should rely on them. The OOo SDK can shield external mechanisms from those---changing---details.) In short, it looks like PUNO would need to be adapted to work with OOo 3. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org For additional commands, e-mail: dev-h...@udk.openoffice.org
Re: [udk-dev] Building PUNO On OOo 3.x
On 05/27/09 15:46, Adam Tauno Williams wrote: On Fri, 2009-05-22 at 10:13 +0200, Stephan Bergmann wrote: On 05/20/09 20:20, Adam Tauno Williams wrote: On one of our webservers with use PUNO (the PHP UNO module http://www.wstech2.net/index.php?do=puno_install) to communicate with OOo running as a service. In that case it is openSUSE 10.3 with OpenOffice_org-2.3.0.1.2-10.5. The module builds an works perfectly. Now we need to deploy on openSUSE 11.1 with OpenOffice_org-3.0.1.3-3.1. But unforunately the module fails to build since [as I interpret it) the UNO API has changed: OK: tar xf puno-0.6.tar.gz Where did you get that tar file from? I do not know what it is. http://sourceforge.net/project/showfiles.php?group_id=197229 I see. OK: cd puno-0.6 OK: /usr/lib/ooo3/basis3.0/sdk/setsdkenv_unix OK: phpize OK: ./configure --with-puno=/usr/lib/ooo3/basis3.0/sdk OK: make cppumaker FAILS: make install (or just make) /usr/lib/ooo3/basis3.0/sdk/include/cppu/unotype.hxx: In static member function 'static const com::sun::star::uno::Type cppu::UnoType template-parameter-1-1 ::get() [with T = int]': /usr/lib/ooo3/basis3.0/sdk/include/cppu/unotype.hxx:293: instantiated from 'const com::sun::star::uno::Type cppu::getTypeFavourUnsigned(const T*) [with T = int]' /usr/lib/ooo3/basis3.0/sdk/include/com/sun/star/uno/Any.hxx:205: instantiated from 'void com::sun::star::uno::operator=(com::sun::star::uno::Any, const C) [with C = int]' /root/puno-0.6/funcs.cpp:232: instantiated from here puno-0.6/funcs.cpp:232 is arguments[0]=xComponentLoader; and xComponentLoader is declared as Reference XComponentLoader xComponentLoader( at l. 184. However, that the complaint is about com::sun::star::uno::operator=(com::sun::star::uno::Any, const C) [with C = int] would imply that at l. 232 the compiler assumes that xComponentLoader is of type int, not of type com::sun::star::uno::Referencecom::sun::star::frame::XComponentLoader. Something seems to go terribly wrong here. What is the exact gcc call that causes the error, and is the given error output the complete output of that gcc call, or just the tail? Also, changing the gcc call to just pre-process the input (instead of compiling it) might give a clue. (I do not have the time to set things up to try this out myself, but if you make available the information, I am willing to have a look.) -Stephan /usr/lib/ooo3/basis3.0/sdk/include/cppu/unotype.hxx:272: error: call of overloaded 'cppu_detail_getUnoType(int*)' is ambiguous /usr/lib/ooo3/basis3.0/sdk/include/cppu/unotype.hxx:159: note: candidates are: const com::sun::star::uno::Type cppu::detail::cppu_detail_getUnoType(const sal_Int32*) near match /usr/lib/ooo3/basis3.0/sdk/include/cppu/unotype.hxx:164: note: const com::sun::star::uno::Type cppu::detail::cppu_detail_getUnoType(const sal_uInt32*) near match make: *** [puno.lo] Error 1 - To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org For additional commands, e-mail: dev-h...@udk.openoffice.org
Re: [udk-dev] Building PUNO On OOo 3.x
On 05/20/09 20:20, Adam Tauno Williams wrote: On one of our webservers with use PUNO (the PHP UNO module http://www.wstech2.net/index.php?do=puno_install) to communicate with OOo running as a service. In that case it is openSUSE 10.3 with OpenOffice_org-2.3.0.1.2-10.5. The module builds an works perfectly. Now we need to deploy on openSUSE 11.1 with OpenOffice_org-3.0.1.3-3.1. But unforunately the module fails to build since [as I interpret it) the UNO API has changed: OK: tar xf puno-0.6.tar.gz Where did you get that tar file from? I do not know what it is. OK: cd puno-0.6 OK: /usr/lib/ooo3/basis3.0/sdk/setsdkenv_unix OK: phpize OK: ./configure --with-puno=/usr/lib/ooo3/basis3.0/sdk OK: make cppumaker FAILS: make install (or just make) /usr/lib/ooo3/basis3.0/sdk/include/cppu/unotype.hxx: In static member function 'static const com::sun::star::uno::Type cppu::UnoType template-parameter-1-1 ::get() [with T = int]': /usr/lib/ooo3/basis3.0/sdk/include/cppu/unotype.hxx:293: instantiated from 'const com::sun::star::uno::Type cppu::getTypeFavourUnsigned(const T*) [with T = int]' /usr/lib/ooo3/basis3.0/sdk/include/com/sun/star/uno/Any.hxx:205: instantiated from 'void com::sun::star::uno::operator=(com::sun::star::uno::Any, const C) [with C = int]' /root/puno-0.6/funcs.cpp:232: instantiated from here /usr/lib/ooo3/basis3.0/sdk/include/cppu/unotype.hxx:272: error: call of overloaded 'cppu_detail_getUnoType(int*)' is ambiguous /usr/lib/ooo3/basis3.0/sdk/include/cppu/unotype.hxx:159: note: candidates are: const com::sun::star::uno::Type cppu::detail::cppu_detail_getUnoType(const sal_Int32*) near match /usr/lib/ooo3/basis3.0/sdk/include/cppu/unotype.hxx:164: note: const com::sun::star::uno::Type cppu::detail::cppu_detail_getUnoType(const sal_uInt32*) near match make: *** [puno.lo] Error 1 Looks like a compiler issue. Which GCC version exactly are you using? (I guess the above tar file comes not from OOo, but from Novell's go-oo fork. In that case, please ask the go-oo folks for help---or switch to the true OOo.) -Stephan - To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org For additional commands, e-mail: dev-h...@udk.openoffice.org
Re: [udk-dev] URE 1.3.0 download
On 05/08/09 18:54, Jeremy Trudel wrote: I am trying to download U.R.E. 1.3.0 from http://download.openoffice.org/2.4.0/ure.html but all the links at the bottom of the page are broken and I can't seem to download anything. No idea where it has gone; Joost knows the details, I assume. In general, since OOo 3.0.0 we have not made available any independent URE downloads any more. Instead, you can extract a freestanding URE from a complete OOo installation set (on Linux and Solaris, where an OOo installation set is just a bundle of packages, it is the one package with ure in its name, installing to /opt/openoffice.org/ure; on Mac OS X and Windows, where there is one monolithic installation set for OOo, it is the sub-directory named ure or URE from an installed OOo, which you can copy to an arbitrary location). (The correspondence between OOo and URE versions is listed at http://wiki.services.openoffice.org/wiki/UNO_%40since_Tags.) Maybe such a more recent URE suites your needs better, anyway? -Stephan - To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org For additional commands, e-mail: dev-h...@udk.openoffice.org
Re: [udk-dev] Re: OpenOffice and PenOffice
Stan, Please give a precise short description what exactly you are doing, ideally a stripped-down test case. (And please consider subscribing to this mailing list, see http://udk.openoffice.org/servlets/ProjectMailingListList, as you might otherwise miss relevant mails that forget to keep you on cc.) -Stephan On 01/30/09 21:10, Stan Miasnikov wrote: Hi Florian, Thorsten, After 2 days of testing we have found the cause of the issue with OpenOffice.org and PenOffice integration. It does not depend on the version of OpenOffice or Windows OS. It works on all 32-bit installations and does not work on 64-bit installations. So, this is apparently a 64-bit issue. Also, it is not something that we can fix in PenOffice, our tests demonstrate that no matter what we do initialization of the OOo document context fails on 64-bit systems (while works on 32-bit systems) in both 3.0 and 3.0.1 versions with the following exception: caught BootstrapException: unexpected UNO exception caught: component context fails to supply service com.sun.star.bridge.UnoUrlResolver of type com.sun.star.bridge.XUnoUrlResolver We'll be happy to assist you in fixing this issue in the future versions of OOo. Let me know if you have any comments/suggestions. Best Regards, Stan On 1/29/09 2:10 PM, Thorsten Behrens t...@openoffice.org wrote: Mikhail Barashkov wrote: I should comment on this that the only idea I have now is that maybe OpenOffice 3.0.1 needs registry .rdb file built against OpenOffice 3.0.1 SDK (the current one is built using 3.0 SDK). The problem is that I don't see a 3.0.1 SDK update available and so I can't build an updated registry file. Sorry folks, this is not exactly my turf, no idea what changes went in there for 3.0.1 - please ask this on the d...@api.openoffice.org and/or dev@udk.openoffice.org list. HTH, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org For additional commands, e-mail: dev-h...@udk.openoffice.org
Re: [udk-dev] Re: openoffice.org-core: Segmentation fault at startup
Reproducing with libstdc++.so.6 and libgcc_s.so.1 from gcc-4.4-20090102 in unxlngi6.pro DEV300m38 OOo, the problem is that OOo at http://svn.services.openoffice.org/ooo/tags/DEV300_m38/bridges/source/cpp_uno/gcc3_linux_intel/share.hxx l. 52 assumes a layout of struct __cxa_exception as given in section 2.2.1 of http://www.codesourcery.com/public/cxx-abi/abi-eh.html, while GCC 4.4 added a new member _Atomic_word referenceCount; to the start of the struct at gcc-4.4-20090102/libstc++-v3/libsupc++/unwind-cxx.h l. 57. OOo tries to get at information stored in the __cxa_exception header in the destructor function passed to __cxa_throw (function deleteException at http://svn.services.openoffice.org/ooo/tags/DEV300_m38/bridges/source/cpp_uno/gcc3_linux_intel/except.cxx l. 213), which now fails. Please somebody clarify if GCC 4.4 adding a new member to struct __cxa_exception (and thus deviating from http://www.codesourcery.com/public/cxx-abi/abi-eh.html) is intended or is a mistake. If it is intended, the OOo code needs to be changed (the information deleteException is now trying to retrieve from the __cxa_exception header must instead be encoded in the deleteException function itself, by dynamically creating instances of deleteException as is already done in the OOo bridges for Solaris). If it is a mistake, the OOo code can stay as is and the GCC 4.4 code needs to be changed instead. On 12/22/08 21:04, Rene Engelhard wrote: tag 504323 - moreinfo tag 504323 - unreproducible retitle 504323 openoffice.org-core: Segmentation fault at startup with gcc 4.4 libs forwarded 504323 dev@udk.openoffice.org thanks [ d...@udk: as usual, please Cc all involved! ] Hi, Florian Goujeon wrote: It was indeed my mistake. I'm working with GCC4.4 svn and installed it in /usr/local. OOo, instead of using the straight /usr/lib's libgcc_s.so.1, used the unstable /usr/local/lib's one. Everything went back to normal once I uninstalled GCC4.4 svn. Yes, confirmed. I get the same crash when setting LD_LIBRARY_PATH to /usr/lib/gcc-snapshot/lib. r...@mini:~$ LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib gdb /usr/lib/openoffice/program/soffice.bin GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as powerpc-linux-gnu... (gdb) run Starting program: /usr/lib/openoffice/program/soffice.bin [Thread debugging using libthread_db enabled] warning: Lowest section in /usr/lib/libicudata.so.38 is .hash at 00b4 [New Thread 0x48054c60 (LWP 30793)] [New Thread 0x4ba294c0 (LWP 30820)] [New Thread 0x4c2294c0 (LWP 30821)] [New Thread 0x4ca864c0 (LWP 30823)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x48054c60 (LWP 30793)] 0x0bb633b0 in deleteException () from /usr/lib/openoffice/program/libgcc3_uno.so (gdb) Seems to be arch-indep (seen on i386 and ppc at least) Unless this is a wrong behavior of OOo, the bug report can be safely closed. Actually I am not sure. It night be a bug in OOo or it might be one in gcc. debian-gcc: (gdb) bt #0 0x0bb633b0 in deleteException () from /usr/lib/openoffice/program/libgcc3_uno.so #1 0x0e884a30 in ?? () from /usr/lib/gcc-snapshot/lib/libstdc++.so.6 #2 0x0e6af8f8 in _Unwind_DeleteException () from /usr/lib/gcc-snapshot/lib/libgcc_s.so.1 #3 0x0e882d10 in __cxa_end_catch () from /usr/lib/gcc-snapshot/lib/libstdc++.so.6 #4 0x0f739e00 in UCBOpenContentSync () from /usr/lib/openoffice/program/libutl680lp.so #5 0x0f73b4a8 in utl::UcbLockBytes::CreateLockBytes () from /usr/lib/openoffice/program/libutl680lp.so #6 0x0f746594 in lcl_CreateStream () from /usr/lib/openoffice/program/libutl680lp.so #7 0x0f74691c in utl::UcbStreamHelper::CreateStream () from /usr/lib/openoffice/program/libutl680lp.so #8 0x0ebdab38 in SfxApplication::GetDisabledSlotList_Impl () from /usr/lib/openoffice/program/libsfx680lp.so #9 0x0ecfb320 in SfxDispatcher::Construct_Impl () from /usr/lib/openoffice/program/libsfx680lp.so #10 0x0ecfb598 in SfxDispatcher () from /usr/lib/openoffice/program/libsfx680lp.so #11 0x0ebd7e54 in SfxApplication::Initialize_Impl () from /usr/lib/openoffice/program/libsfx680lp.so #12 0x0ebcf834 in SfxApplication::GetOrCreate () from /usr/lib/openoffice/program/libsfx680lp.so #13 0x0ed1a86c in SfxGlobalEvents_Impl () from /usr/lib/openoffice/program/libsfx680lp.so #14 0x0ed1aa5c in SfxGlobalEvents_Impl::impl_createInstance () from /usr/lib/openoffice/program/libsfx680lp.so #15 0x0f39991c in cppu::OSingleFactoryHelper::createInstanceEveryTime () from /usr/lib/openoffice/program/libuno_cppuhelpergcc3.so.3 #16 0x0f3989fc in cppu::OSingleFactoryHelper::createInstanceWithContext () from
Re: [udk-dev] Re: Bug#505669: marked as forwarded (Causes FTBFS with GCC 4.4: gcc 4.4 not supported)
On 11/17/08 16:01, Rene Engelhard wrote: So it seems we can remove it finally? It would really be nice for OOo just working without manual fiddling with a new compiler, if the compiler itself works/OOos code is buildable with it. I guess nobody would complain if you reduced the GCC case to something like #elif __GNUC__ = 3. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Workarounds for pyuno problems in OOo3.0.0
@setori88: You should not modify neither redirect.ini nor soffice.ini
(likely, OOo will not work at all if you do so). Rather, in the
environment where you start OOo's python.exe, you need to set the
environment variable URE_BOOTSTRAP, to either something like either
file:///C:/Program%20Files/OpenOffice.org%203/program/fundamental.ini
or
vnd.sun.star.pathname:C:\Program Files\OpenOffice.org
3\program\fundamental.ini
(adapted to your actual OOo installation path).
@jbu: However, when I try the scenario described by setori88 on a Win
XP box (execute
[C:\] C:\Program Files\OpenOffice.org 3\program\swriter.exe
-accept=socket,host=localhost,port=2002;urp
[C:\] set URE_BOOTSTRAP=vnd.sun.star.pathname:C:\Program
Files\OpenOffice.org 3\program\fun
[C:\] C:\Program Files\OpenOffice.org 3\program\python.exe
C:\hello_world.py
where hello_world.py is as given at
http://udk.openoffice.org/python/python-bridge.html) I get the error
Traceback (most recent call last):
File C:\\hello_world.py, line 11, in ?
ctx = resolver.resolve(
uno:socket,host=localhost,port=2002;urp;StarOffice.ComponentContext )
__main__.com.sun.star.connection.NoConnectException: Connector :
couldn't connect to socket (WSANOTINITIALISED, WSAStartup() has not been
called)
instead. Seen that before? Any idea whether it is a fault of
python.exe or of URE?
Also, I have to admit I lost track why the problem of python.exe not
working on Windows due to missing URE_BOOTSTRAP exists at all. On Unix,
we solved the problem (at least for those OOo builds that use OOo's own
python executable, not a system one) with an appropriate python shell
script wrapper around a python.bin. On Windows, such a wrapper appears
to be missing. Was that an oversight, or did we have any reason to do
it that way? Does an issue exist for this problem?
-Stephan
On 10/16/08 06:04, setori88 wrote:
[...]
I still cant get point 4 to work properly.
here is what I am doing:
- after i change office/program/redirect.ini
[Bootstrap]
URE_BOOTSTRAP=fundamental.ini
(it was URE_BOOTSTRAP=${ORIGIN}/fundamental.ini)
- I also change office/program/soffice.ini
[Bootstrap]
Logo=1
ProgressBarColor=4,68,155
ProgressFrameColor=58,159,232
ProgressPosition=14,230
ProgressSize=412,7
URE_BOOTSTRAP=fundamental.ini
HideEula=1
(it was URE_BOOTSTRAP=${ORIGIN}/fundamental.ini)
- run soffice -accept=socket,host=localhost,port=2002;urp;
- the helloworld.py script is in the office/program dir.
which is a copy and paste of
http://udk.openoffice.org/python/python-bridge.html helloworld.py example
- I call python helloworld.py (using openoffice's python) from
office/program dir
I get the error no 4's error
AttributeError: getCurrentComponent
[...]
Jörg Budischewski wrote:
[...]
4) (windows only) The python program crashes or you get an attribute error
AttributeError: getCurrentComponent (or some other attribute)
This is because the types could not be loaded due to changes in the uno
bootstrapping mechanism. You can work around it for now by setting the
variable set URE_BOOTSTRAP=fundamental.ini
and running python from the
path/to/office/OpenOffice.org 3/programdirectory.
[...]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] [EMAIL PROTECTED]: Bug#501028: python-uno: Can't get types when using Python bindings]
On 10/05/08 20:39, Rene Engelhard wrote: [ please keep [EMAIL PROTECTED] in Cc ] Hi, do you have any idea on this? My python packages actually use system-python but it worked in the 2.4.1 packages so it must have been broken by some 3 layer stuff). Some of the libs/.pys are in pythons site-packages because python otherwise didn't find them[1]. Regards, Rene As I already wrote, see http://www.openoffice.org/issues/show_bug.cgi?id=90701 for further details. -Stephan -- Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] python-uno bindings break with OO.o 3.0 and system python
On 10/07/08 14:49, Tim Retout wrote: [This is a follow-up to a mail by Rene Engelhard which got caught in the [EMAIL PROTECTED] moderation queue. See http://bugs.debian.org/501028 ] The OpenOffice.org program/python script sets URE_BOOTSTRAP which contains the location of fundamentalrc. In turn, fundamentalrc sets the location of the offapi.rdb file, which contains information about the types used by the python uno bindings. In short, when --with-system-python is used with OO.o 3.0, these variables don't get set, so we see the types breakage described in the Debian bug report. One workaround is to export an appropriate URE_BOOTSTRAP variable before running python. The alternative is to check for and set this variable in uno.py, which will cover most use cases transparently - I'm halfway through writing this patch. Also see http://www.openoffice.org/issues/show_bug.cgi?id=90701. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] My first Calc addin: problem with exception handling
On 08/24/08 20:10, Andrea wrote:
Hi,
I've just written my first Calc addin and I managed to get my functions in Calc.
Now I have tried to throw exception (RuntimeException or
IllegalArgumentException) but the whole
application crashes as soon as an exception is thrown.
I get
terminate called after throwing an instance of
'com::sun::star::uno::RuntimeException'
which seems to come from g++ rather then OO.
Even an exception thrown inside a try{} catch(...){} crashes everything.
I have read that one should use the same compiler used to compile OO.
Is it (still) true? Is this my problem? What about dependent libraries?
I am using Fedora 9, gcc 4.3.0, OO openoffice.org-core-2.4.1-17.4.fc9-i386.
How do I find which compiler was used?
A GCC 4 should be fine. For C++ exception handling to work reliably
with GCC, the executable and all dynamic libraries need to use the same
definitions of RTTI symbols (symbols starting with _ZTI and _ZTS) for
exception types. What is the output of nm -d on your library? Did
you build your library with the OOo SDK?
-Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Re: My first Calc addin: problem with exception handling
On 08/25/08 10:05, Andrea wrote: Can I ask an other question: I cannot set breakpoints in my library. (gdb) attach 3459 Attaching to program: /home/andrea/projects/openoffice/maths/libASIMaths.so, process 3459 0x00110416 in __do_global_dtors_aux () (gdb) break ASIMaths_impl.cpp:73 Breakpoint 1 at 0x110ee8: file ASIMaths_impl.cpp, line 73. (gdb) c Continuing. But then it never stops. I compile and link with -g. Should I do anything more? Sorry, no idea. Maybe gdb thinks that line 73 of your file contains no code (like only the void f() start of a function definition). -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Error while writing a OOCalc-Addin with Java
find my answer at [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] How can I add a interface upon a published service?
Rainman Lee wrote:
Oh, I see..:@(
I think it is a problem coming with the new-style interfaces, right?
if I wrote the service S using the old-style interface statement like this:
service S
{
interface A;
interface B;
}
then, the only thing I would have to do to introduce a new interface D could be:
service S
{
interface A;
interface B;
interface D; //simply add this statement and implement somewhere.
}
Is that right?
No. Adding non-optional interfaces to old-style services is not
allowed, as it would break old implementations of that service. (Adding
optional interface to old-style services had been allowed, although it
is now known to be broken.)
-Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] How can I know which service implementation is contained in URE?
Rony G. Flatscher wrote: Cédric Bosdonnat wrote: Simply use the regview SDK tool on the types.rdb and services.rdb files contained in the ure share/misc directory. Then you'll see all the API available in the URE and the mapping the services and their implementations. Is there maybe a base module that is always available in URE (from which one could find all other modules and its members)? what do you mean with base module? -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Simple Bootstrap on OOo-3-M2 on Windows, setup ? (Re: [udk-dev] Simple Bootstrap
Rony G. Flatscher wrote: Stephan Bergmann wrote: Oliver Braun wrote: Stephan Bergmann wrote: See http://www.openoffice.org/issues/show_bug.cgi?id=88687, addressed all three problems with a newly introduced unoinfo program there. Does the new mechanism still rely on a symbolic link named 'soffice' being present in some directory which is in PATH by default (which in turn is the reason why we install /usr/bin/soffice atm.) ? Yes. That part of simple bootstrap did not change, the mechanism still needs to find an office installation (via PATH, UNO_PATH, Windows registry...). Just a question ad the Windows-installation of OOo-3.0-M2: that version does not (yet) incorporate the unoinfo utility, so I tried to set up the environment by hand, but am missing something as the binary cannot be found when excercising the bootstrap mechanism: *com.sun.star.comp.helper.BootstrapException: no office executable found!* Obviously, something is wrong. The path to soffice.exe/soffice.bin is given, as are the full paths to jurt.jar, unoil.jar, ridl.jar and juh.jar in CLASSPATH: PATH=e:\jdk1.6.0_02\bin;D:\WINDOWS\system32;D:\WINDOWS;D:\WINDOWS\System32\Wbem;e:\cygwin\bin;e:\rony\tools;E:\vslick\win;E:\Programme\GNU\GnuPG\pub;D:\Programme\Gemeinsame Dateien\GTK\2.0\bin;D:\Programme\ooRexx;d:\Programme\Microsoft SQL Server\90\Tools\binn\;D:\Programme\SSH Communications Security\SSH Secure Shell;e:\jdk1.6.0_02\jre\bin\client;e:\rony\dev\bsf\src\bin;D:\Programme\OpenOffice.org 3\program CLASSPATH=e:\rony\dev\bsf\src;.;D:\Programme\OpenOffice.org\URE\java\jurt.jar;D:\Programme\OpenOffice.org\Basis 3.0\program\classes\unoil.jar;D:\Programme\OpenOffice.org\URE\java\ridl.jar;D:\Programme\OpenOffice.org\URE\java\juh.jar;D:\Programme\OpenOffice.org\Basis 3.0\program\classes Is there some jar missing? Do I need to set a special Windows registry key (the default OOo installation points to 2.4 in the key 'Software\OpenOffice.org\UNO\InstallPath')? When will there be the next developer version containing the unoinfo.exe? It might work if you add the OOo 3 brand layer program directory (D:\Programme\OpenOffice.org 3\program) to the CLASSPATH. Otherwise, wait until http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fsb87 is integrated. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] python vs. python.sh confusion
Jörg Budischewski wrote: Hi, python is the public interface, python.sh is an implemetation detail. I actually introduced this because I didn't know how to create a python script with our installation procedure when there is the python as executable in the solver path in the build environment. (In the build env, it is ok to just call python executable as the appropriate environment gets set by the global build env scropt). I see. Got that fixed now on CWS sb87 (delivering python.sh as solver's bin/pyuno/python and referencing it as pyuno/python in scp2 does the trick); i.e., there is no python.sh any longer in the installed product, just python (and also on Windows the wrapper changed from python.bat to python.exe). -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[udk-dev] python vs. python.sh confusion
Why are there both a pyhton.sh and a python symlink to it in the program directory of OOo 2.x (when defined UNX !defined SYSTEM_PYTHON)? Are both part of the OOo public interface (intended to be called by clients), or should one or the other be considered an implementation detail? -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Simple Bootstrap
Oliver Braun wrote: Stephan Bergmann wrote: See http://www.openoffice.org/issues/show_bug.cgi?id=88687, addressed all three problems with a newly introduced unoinfo program there. Does the new mechanism still rely on a symbolic link named 'soffice' being present in some directory which is in PATH by default (which in turn is the reason why we install /usr/bin/soffice atm.) ? Yes. That part of simple bootstrap did not change, the mechanism still needs to find an office installation (via PATH, UNO_PATH, Windows registry...). -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Simple Bootstrap
Stephan Bergmann wrote: Unfortunately, with the advent of the Three-Layer Office (http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/Three-Layer_OOo, starting DEV300m4) both the C++ and Java simple bootstrap mechanisms (http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/C%2B%2B/Transparent_Use_of_Office_UNO_Components and http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/Transparent_Use_of_Office_UNO_Components) no longer work. The problems are as follows: 1 C++ unoapploader on Unix (Linux, Solaris): Determines the location of an soffice application, adds the soffice path to LD_LIBRARY_PATH (so that the subordinate process finds the URE libraries, which used to be located next to the soffice application), and then spawns the subordinate process. This no longer works, as the URE libraries are now located somewhere else. 2 C++ unoapploader.exe on Windows: Determines the location of an soffice application, adds the soffice path to PATH (so that the subordinate process finds the URE libraries, which used to be located next to the soffice application), and then spawns the subordinate process. This no longer works, as the URE libraries are now located somewhere else. 3 Java com.sun.star.lib.loader.Loader: Determines the location of an soffice application, locates classes/juh.jar relative to the soffice path, calls com.sun.star.comp.helper.UnoInfo.getJars there (which returns the list of URE jar URLs), and loads the subordinate application in a class loader that knows the URE jars. This no longer works, as juh.jar is now located somewhere else. Problem 3 could most silently be fixed by adding a fake classes/juh.jar (containing only a modified com.sun.star.comp.helper.UnoInfo.getJars that returns the correct list of URE jar URLs) to each brand layer. The advantage is that an old Loader continues to work against a new soffice installation. The disadvantage is the somewhat dirty solution (have a classes subdir only for the fake juh.jar, have a fake juh.jar with the same name as the true juh.jar in the URE). Problem 1 could most silently be fixed by adding symbolic links for all the URE libraries to all brand layer program directories. The advantage is that an old unoapploader continues to work against a new soffice installation. The disadvantage is the somewhat dirty solution (quite a number of symlinks, not for general use but just for unoapploader to be happy). Problem 2 cannot be silently fixed, however. The only solution I see is to change the Windows unoapploader.exe as follows: Determine the location of an soffice application and check whether there is an executable called (say) ureinfo next to it. If yes (i.e., new soffice installation) call it and (if successful exit status) use its stdout data to extend PATH. If no (i.e., old soffice installation) extend PATH with the soffice path, as before. In either case, proceed as before (spawn subordinate application). The disadvantage, of course, is that an old unoapploader will no longer work against a new soffice. Given that problem 2 needs an incompatible solution, anyway, the question is, for each of the problems 1 and 3, whether to go with a compatible but somewhat dirty solution, or too go with a clean but incompatible solution. (In all three cases the same sketched ureinfo could be called by the loaders, parameterized on stdin whether to supply information for C++ or for Java.) For problem 1 my opinion is to go with the same solution as for problem 2 (i.e., call the sketched ureinfo on all platforms from the C++ unoapploaders, and thus have an incompatible change in the C++ unoapploaders of all platforms). For problem 3 I am somewhat undecided (and, out of laziness, would probably go with the fake classes/juh.jar wart, as it would be less work to implement). More opinions, anybody? -Stephan See http://www.openoffice.org/issues/show_bug.cgi?id=88687, addressed all three problems with a newly introduced unoinfo program there. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] defaultBootstrap_InitialComponentContext()
Rony G. Flatscher wrote: Hi there, could you give a brief/short example in Java (pseudo-code or a sequence of the necessary API invocations would suffice) how one would get to an office with the suggested/planned changes in place (and if no office process is up, how to start one up and have it initialized) which would work on all platforms? The simple bootstrap mechanism described at http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/Transparent_Use_of_Office_UNO_Components should continue to work. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Simple Bootstrap
Rony G. Flatscher wrote: Stephan Bergmann wrote: Unfortunately, with the advent of the Three-Layer Office (http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/Three-Layer_OOo, starting DEV300m4) both the C++ and Java simple bootstrap mechanisms (http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/C%2B%2B/Transparent_Use_of_Office_UNO_Components and http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/Transparent_Use_of_Office_UNO_Components) no longer work. The problems are as follows: ... cut ... 3 Java com.sun.star.lib.loader.Loader: Determines the location of an soffice application, locates classes/juh.jar relative to the soffice path, calls com.sun.star.comp.helper.UnoInfo.getJars there (which returns the list of URE jar URLs), and loads the subordinate application in a class loader that knows the URE jars. This no longer works, as juh.jar is now located somewhere else. Problem 3 could most silently be fixed by adding a fake classes/juh.jar (containing only a modified com.sun.star.comp.helper.UnoInfo.getJars that returns the correct list of URE jar URLs) to each brand layer. The advantage is that an old Loader continues to work against a new soffice installation. The disadvantage is the somewhat dirty solution (have a classes subdir only for the fake juh.jar, have a fake juh.jar with the same name as the true juh.jar in the URE). ... cut ... Just a question here: in order to allow for using OOo 2.x from Java, I have a setup routine that defines the classpath to point to OOoHome/program/classes/jurt.jar, OOoHome/program/classes/unoil.jar, OOoHome/program/classes/ridl.jar, and OOoHome/program/classes/juh.jar. Would that setup still work for OOo 3.x? If not, what is the recommended setup for classpath then? No, that will no longer work. OOo is now split in three trees (URE, Basis, Brand), and the necessary jars are spread across two of those trees (jurt, ridl, juh in URE; unoil in Basis). If you are happy with a manual setup (for which there are no guarantees of stability, of course), see http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/Three-Layer_OOo for details of how the lower (URE, Basis) layers can be located from the Brand layer (which probably most closely corresponds to what you denote OOoHome above). Or, better, try to use the simple bootstrap mechanisms instead of a manual setup---we will try to keep those mechanisms as stable as possible (though, as this thread shows, there are situations when that stability cannot be absolute). -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Simple Bootstrap
Rony G. Flatscher wrote: Just a question here: in order to allow for using OOo 2.x from Java, I have a setup routine that defines the classpath to point to OOoHome/program/classes/jurt.jar, OOoHome/program/classes/unoil.jar, OOoHome/program/classes/ridl.jar, and OOoHome/program/classes/juh.jar. Would that setup still work for OOo 3.x? If not, what is the recommended setup for classpath then? No, that will no longer work. OOo is now split in three trees (URE, Basis, Brand), and the necessary jars are spread across two of those trees (jurt, ridl, juh in URE; unoil in Basis). If you are happy with a manual setup (for which there are no guarantees of stability, of course), see http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/Three-Layer_OOo for details of how the lower (URE, Basis) layers can be located from the Brand layer (which probably most closely corresponds to what you denote OOoHome above). Or, better, try to use the simple bootstrap mechanisms instead of a manual setup---we will try to keep those mechanisms as stable as possible (though, as this thread shows, there are situations when that stability cannot be absolute). Hmm, at the moment I have a script that will create another script which sets up the environment according to the individual installation. It sets the classpath according to the current (old?) documentation for OOo. (In the 1.x-times sandbox.jar was among those jars that needed to be made available.) Java in this use-case serves as the layer to access/remote-control OOo for the interpreted scripting language ooRexx (using a Rexx-to-Java-bridge). As a consequence for this to work Java reflection is employed and therefore Java needs to be able to access all the Java classes that are defined in the OOo jars. Given your explanation, one solution might be to determine at setup-time the version of OOo that is installed and create that dispatcher script according to it (hence in the 3.x case having classpath point to the jars in URE and Basis). For this scenario to work reliably it must be possible then to determine the paths to the three layers on all platforms (probably registry entries on Windows, some other means for Unix-installations). Is an appropriate detection mechanism defined already? [Maybe even an OOo-supplied utility that would write those paths to stdout?] For OOo 2, the Java code com.sun.star.comp.helper.UnoInfo.getJars in ooo-installation/program/classes/juh.jar does just that. As I wrote in the mail originating this thread, for OOo 3 we should either fix things so that ooo-installation(-brand-layer)/program/classes/juh.jar continues to work, or introduce a new ooo-installation(-brand-layer)/program/ureinfo (or somesuch) that replaces it (and would become a part of OOo's stable interface, hopefully still working with OOo 4 etc.). The latter would probably be easier for you to use, not having to call Java code from your script. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Description file for an extension
Bernard Marcelly wrote: Hi, Reading the on-line Developer's Guide 5.5.2 example of a file description.xml http://api.openoffice.org/docs/DevelopersGuide/Extensions/Extensions.xhtml#1_5_2_Example I think I found two typing errors, or at least inconsistency with the description of the element attributes in the preceding pages: Second line reads: xmlns:d=http://openoffice.org/extensions/description/2006; should be: xmlns:dep=http://openoffice.org/extensions/description/2006; Seventh line reads: OpenOffice.org-minimal-version value=2.2 d:name=OpenOffice.org 2.2/ should be: OpenOffice.org-minimal-version value=2.2 dep:name=OpenOffice.org 2.2/ Do you agree ? Do you want that I create an Issue ? Yes, there is an editorial inconsistency (but not an error). I would suggest you wait until the Dev Guide is only in the Wiki (hopefully soon?) and correct it there yourself. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Another question on Clear Separation of C and CPP andCore Componenets.
Cynthia Qu wrote:
hi,Stephan,
Happy holiday season! And thank you very much for your reply! :-)
Stephan Bergmann wrote;
First and foremost (even though you probably will not like to hear
that), I personally think the Clear Separation of C and Cpp and Core
Components thing is nothing we should waste our time with. (I know,
Kay Ramme thinks differently, hence he put that on the todo list.) Too
much potential to break existing client code, with only very little
(IMO) to gain.
Yes? I thought anything put on to do list is need to do. But I am not sure if
it is assigned to me or not. And I am confussed about I need to keep on doing it or not.
:(
I cannot really give you advice on this. As I said, whether or not this
is a useful todo is somewhat controversial. (Sorry, I could have
raised my concerns earlier in this thread; if I remember correctly I did
bring this up in discussion with Xiuzhi a while ago, though.)
3.I don't understand what has done in the fuction _defaultConstructUnion :
inline void _defaultConstructUnion(
void * pMem,
typelib_TypeDescription * pTypeDescr )
SAL_THROW( () )
{
::uno_type_constructData(
(char *)pMem + ((typelib_UnionTypeDescription
*)pTypeDescr)-nValueOffset,
((typelib_UnionTypeDescription *)pTypeDescr)-pDefaultTypeRef );
*(sal_Int64 *)pMem = ((typelib_UnionTypeDescription
*)pTypeDescr)-nDefaultDiscriminant;
}
***
At some places in the UNO code, there is provision for a union (aka sum)
data type construct, which obviously was planned for at the beginning of
UNO, but never implemented completely nor removed completely.
I am sorry, I am not sure what you mean about aka sum. Is it also known as sum? Why can't I
find out sum key word in cppu module? Am I misunderstand?
Sorry, that probably confused more than it clarified: In some circles,
union data types are called sum data types (google for algebraic
type systems for further details).
4.Can I just move out the code class Enterable in cppu/inc/cppu/Enterable.hxx and put it into a
file in cppuhelper/inc/Enterable.hxx (new created in this folder), but keep the other extern
C inline stuff without moving?
No. At compile time, client code expects #include cppu/Enterable.hxx
to define class cppu::Enterable. We have a policy in place to not break
(legal) client code, neither at compile time nor at runtime.
I am sorry. What does the client code refer to ? And as the extern C stuffs are
compiled with C compiler(I thought), then it should offer C APIs, why is it dependent on C++ at runtime ? How to know
the policy you refered above, could you give me some reference or explain? And do you know how to make
dependency against C++ is only at compile time to use the C++ compiler, but nothing at runtime?
Client code is any code external to the URE that uses the URE.
I am not sure we have our compatibility policy written down somewhere
explicitly, but the idea is simple: Do not change the URE's published
interface in any way that makes existing, legal (i.e., only relying on
the published interface) code fail, either at compile or a runtime.
Awaiting for your earliest reply!
May you and your family have a bright Christmas!
Have a nice time, too.
-Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Another question on Clear Separation of C and CPP and Core Componenets.
Cynthia Qu wrote:
hi, Stephan,
Thank you very much for your kindness reply! I got it ,then. :)
I also have other questions:
1.How to make sure I have moved out all of the C++ stuff we need to move?
First and foremost (even though you probably will not like to hear
that), I personally think the Clear Separation of C and Cpp and Core
Components thing is nothing we should waste our time with. (I know,
Kay Ramme thinks differently, hence he put that on the todo list.) Too
much potential to break existing client code, with only very little
(IMO) to gain.
2.What is the workflow of the task described here: http://wiki.services.openoffice.org/wiki/Uno/Todo/Clear_Separation_of_C_and_Cpp_and_Core_Components . Well, I mean how to get you know what I have done about the task, if I thought I have completed it ? Shall I need to do all of the tasks described in the link page and then inform you, or inform you after each task I have done and let you check out if I have done it right,then move on?
3.I don't understand what has done in the fuction _defaultConstructUnion :
inline void _defaultConstructUnion(
void * pMem,
typelib_TypeDescription * pTypeDescr )
SAL_THROW( () )
{
::uno_type_constructData(
(char *)pMem + ((typelib_UnionTypeDescription
*)pTypeDescr)-nValueOffset,
((typelib_UnionTypeDescription *)pTypeDescr)-pDefaultTypeRef );
*(sal_Int64 *)pMem = ((typelib_UnionTypeDescription
*)pTypeDescr)-nDefaultDiscriminant;
}
***
At some places in the UNO code, there is provision for a union (aka sum)
data type construct, which obviously was planned for at the beginning of
UNO, but never implemented completely nor removed completely.
4.Can I just move out the code class Enterable in cppu/inc/cppu/Enterable.hxx and put it into a
file in cppuhelper/inc/Enterable.hxx (new created in this folder), but keep the other extern
C inline stuff without moving?
No. At compile time, client code expects #include cppu/Enterable.hxx
to define class cppu::Enterable. We have a policy in place to not break
(legal) client code, neither at compile time nor at runtime.
-Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] what is class Type used for?
Cynthia Qu wrote: Hi,all, May you have a nice holiday season! And Merry Christmas! ^_^ Could anybody of the list tell me what the class Type which is defined in cppu/inc/com/sun/star/uno/Type.h is used only for C++ UNO or both of C UNO and C++ UNO ? What does it used for? I just got know it does something between types of IDL and UNO. I am not sure if I should move it out of cppu or not, for I thought it has something to do with C UNO. I need your support! Thank you in advance! :-) It is only used for C++. Typically, it is not included directly, but indirectly via com/sun/star/uno/Type.hxx (which defines the relevant inline functions of class com::sun::star::uno::Type). The class com::sun::star::uno::Type is the representation in the C++ UNO language binding of the UNO type TYPE (just as for example the class com::sun::star::uno::Any is the representation in the C++ UNO language binding of the UNO type ANY, or sal_Int32 is the representation in the C++ UNO language binding of the UNO type LONG). -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Does URE has everything OOo has for a developer?
Alexandro Colorado wrote: Hi people, Does URE contains all the components from the original OOo. Is it possible to do file conversions the same way you will do if you had the complete OOo application? My guess is that yes but I am particularly curious on things like dispatcher but I haven't write in Java so I am not sure if there is even a dispatcher for Java. No, URE contains just the UNO runtime system, none of the Office functionality parts of OOo. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Problem on UNO Type System.
Cynthia Qu wrote: hi, all, I have a problem on reading wiki of the UNO Type System ( http://udk.openoffice.org/common/man/typesystem.html ). As I got the following example from wiki here: type S: set of interface type type M: map from integer to member function function fI(t: interface type, T: S, n: integer, μ: M): 〈S, integer, M〉 if t ∉ T // There are some problem on showing the symbol here, so please see the wiki . for i ← 1 … kb [...] I don't know what it is meaning of for i ← 1 … kb , and I don't know what exactly meaning of the arrow points to left here ←. Could any body here give me some explain? Thank you very much! The arrow means assignment, so i is taking on values from 1 to kb, inclusive, one after another. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Question on C++ Uno Runtime.
quch wrote: 4. Is URE that we can download from OOo , like http://download.openoffice.org/2.3.0/ure.html , pakaged by building OOo source? And is it provided by our UDK project? Is this URE the same meaning with the UNO Runtime in C UNO Runtime ? Yes, the URE product you can download is one of the products that are built when you build the whole OOo source code (all the products are built in module instsetoo_native; most if not all of the code that is packaged into it is comming from modules that are part of the UDK project). -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] evolving API
Stephan Bergmann wrote: Frank Schönheit - Sun Microsystems Germany wrote: Thus, I would even vote for relaxing the compatibility restrictions: Heck, please allow me to add new interfaces/properties/attributes to existing services/interfaces while they grow. Don't let us stay with a 5-year-old design just because in a very esoteric theory, somebody could have created another implementation of this service. OOo is evolving, why isn't its API allowed to evolve in a *usable* way? I know, I know. Thinking once again about it, a cheap peace offering could be the introduction of an extensible keyword for interfaces and the concept of interface ownership: - You must not implement objects that have an extensible interface unless you are the owner of that interface (that implies that you must not introduce service or singleton specifications that implement that interface, either). - You cannot inherit other interfaces from an extensible interface. - The owner of an extensible interface can add members to its end (inherited interfaces, methods, attributes). Not completely thought through, but should probably work. How does that sound? Not thought through enough, unfortunately: The general UNO way to compute function indices (see http://udk.openoffice.org/common/man/typesystem.html) sorts all direct attributes before all direct methods of an interface, and at least the binary-UNO--C++-UNO bridge and the URP protocol rely on this function index definition. Further removing the right to add attributes at the end of extensible interfaces would limit the usefulness of such an extensible concept even more, to the point where it becomes ridiculous. So, it seems the splendid days when we will have our cake and actually eat it too are once again not in sight. Fuck it. :( -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[udk-dev] Re: [udk-cvs] CVS update [cws_src680_os2port02]: /udk/cppuhelper/source/
Yuri Dario wrote: Hi Stephan, The generic gcc3.map contains wildcarded entries like _ZN4cppu13ClassDataBaseC1E?; I saw them, but I don't know how to handle wildcards with os2 tools. e.g. I cannot export a symbol using a wildcard, I need an exact match. The build system is quite complex to follow, so I don't see how unix platforms can handle wildcards. If you are giving them directly to gcc, this is a no way for me; but you if run grep/find/awk/*, maybe I can implement the same logic, just tell me how it is supposed to work. Ah, I see. The GNU linker handles wildcards by itself, so on Linux we pass those entries unmodified. However, Mac OS X has the same problem, and uses some tooling to expand wildcards based on what the linked objects define. I cc'ed [EMAIL PROTECTED], maybe someone there can give the relevant pointers. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[udk-dev] Re: [udk-cvs] CVS update [cws_src680_os2port02]: /udk/cppuhelper/source/
[EMAIL PROTECTED] wrote:
Tag: cws_src680_os2port02
User: ydario
Date: 2007-09-29 16:25:07+
Added:
udk/cppuhelper/source/gcc3os2.map
Modified:
udk/cppuhelper/source/makefile.mk
Log:
Issue number: i82034
Submitted by: ydario
Reviewed by: ydario
Commit of changes for OS/2 CWS source code integration.
File Changes:
Directory: /udk/cppuhelper/source/
==
File [added]: gcc3os2.map
Url:
http://udk.openoffice.org/source/browse/udk/cppuhelper/source/gcc3os2.map?rev=1.1.2.1content-type=text/vnd.viewcvs-markup
Added lines: 366
UDK_3_0_0 {
global:
GetVersionInfo;
_ZN3com3sun4star3uno19WeakReferenceHelperC1ERKNS2_9ReferenceINS2_10XInterfaceEEE;
_ZN3com3sun4star3uno19WeakReferenceHelperC1ERKS3_;
[...]
Dario,
There was recently some effort to consolidate different map files for
GCC based platforms. I would assume the OS/2 version would also already
be covered by that or can be covered with only slight changes to the
generic gcc3.map.
The generic gcc3.map contains wildcarded entries like
_ZN4cppu13ClassDataBaseC1E?;
and
_ZThn*_N4cppu14OWeakAggObject7acquireEv;
to cover the variations.
-Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[udk-dev] Re: [udk-cvs] CVS update: /udk/cppu/source/uno/data.cxx
[EMAIL PROTECTED] wrote: User: vg Date: 2007-09-20 14:44:23+ Modified: udk/cppu/source/uno/data.cxx Log: INTEGRATION: CWS os2port01 (1.29.18); FILE MERGED 2007/08/06 10:35:03 obr 1.29.18.2: RESYNC: (1.29-1.30); FILE MERGED 2006/12/28 14:53:44 ydario 1.29.18.1: OS/2 initial import. File Changes: Directory: /udk/cppu/source/uno/ File [changed]: data.cxx Url: http://udk.openoffice.org/source/browse/udk/cppu/source/uno/data.cxx?r1=1.30r2=1.31 Delta lines: +5 -5 --- --- data.cxx2006-09-17 00:21:05+1.30 +++ data.cxx2007-09-20 14:44:20+1.31 @@ -356,18 +356,18 @@ //## -#if OSL_DEBUG_LEVEL 0 +#if OSL_DEBUG_LEVEL 10 Was the above change (effectively removing the BinaryCompatible_Impl test from standard debug builds, IIUC) really intended? -Stephan #include stdio.h -#ifdef SAL_W32 -# pragma pack(push, 8) +#if defined( SAL_W32) +#pragma pack(push, 8) #elif defined(SAL_OS2) -# pragma pack(8) +#pragma pack(push, 4) #endif #if defined(INTEL) \ - (defined(__GNUC__) (defined(LINUX) || defined(FREEBSD)) || defined(MACOSX) \ + (defined(__GNUC__) (defined(LINUX) || defined(FREEBSD) || defined(OS2)) || defined(MACOSX) \ || defined(__SUNPRO_CC) defined(SOLARIS)) #define MAX_ALIGNMENT_4 #endif - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] evolving API
Frank Schönheit - Sun Microsystems Germany wrote: Hi Stephan, http://www.openoffice.org/issues/process_bug.cgi for the records. Please cite the URL of the page before ;) Oops, lost in copy-n-paste... http://www.openoffice.org/issues/show_bug.cgi?id=80946 -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] evolving API
Frank Schönheit - Sun Microsystems Germany wrote: Thus, I would even vote for relaxing the compatibility restrictions: Heck, please allow me to add new interfaces/properties/attributes to existing services/interfaces while they grow. Don't let us stay with a 5-year-old design just because in a very esoteric theory, somebody could have created another implementation of this service. OOo is evolving, why isn't its API allowed to evolve in a *usable* way? I know, I know. Thinking once again about it, a cheap peace offering could be the introduction of an extensible keyword for interfaces and the concept of interface ownership: - You must not implement objects that have an extensible interface unless you are the owner of that interface (that implies that you must not introduce service or singleton specifications that implement that interface, either). - You cannot inherit other interfaces from an extensible interface. - The owner of an extensible interface can add members to its end (inherited interfaces, methods, attributes). Not completely thought through, but should probably work. How does that sound? -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] evolving API
Frank Schönheit - Sun Microsystems Germany wrote: Hi Stephan, I know, I know. Thinking once again about it, a cheap peace offering uh, sorry for the rant then - it wasn't intended as declaration of war :) No problem. I did not really interpret it as such, either. could be the introduction of an extensible keyword for interfaces and the concept of interface ownership: - You must not implement objects that have an extensible interface unless you are the owner of that interface (that implies that you must not introduce service or singleton specifications that implement that interface, either again unless you're the owner, right? Yes. ). - You cannot inherit other interfaces from an extensible interface. except other extensible interfaces? No (see below for rationale). - The owner of an extensible interface can add members to its end (inherited interfaces, methods, attributes). Why at the end only? Do we gain something with this restriction, and do we gain it in *all* language bindings, or would some bindings break regardless of it? The C++ language binding would not (without modifications I would not dare to think about) be able to handle anything else (incl. inheriting from extensible interfaces). So this sketch of a proposal is written from the perspective of how can we modify existing interfaces without the current C++ language binding breaking down when mixing clients compiled against old interface versions with producers built against new interface versions. (All other languages should be more flexible here, so that I assume no extra problems for other language bindings.) Not completely thought through, but should probably work. How does that sound? Like a great first step towards a living API, which is fun to design, without feeling blocked unnecessarily. Come on, the real fun is creatively pressing new functionality into existing, rigid API. :) -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] evolving API
Frank Schönheit - Sun Microsystems Germany wrote: Hi Stephan, - The owner of an extensible interface can add members to its end (inherited interfaces, methods, attributes). Why at the end only? Do we gain something with this restriction, and do we gain it in *all* language bindings, or would some bindings break regardless of it? The C++ language binding would not (without modifications I would not dare to think about) be able to handle anything else (incl. inheriting from extensible interfaces). So this sketch of a proposal is written from the perspective of how can we modify existing interfaces without the current C++ language binding breaking down when mixing clients compiled against old interface versions with producers built against new interface versions. (All other languages should be more flexible here, so that I assume no extra problems for other language bindings.) Yes, the at the end cried C++ loudly ... Sadly, this implies that semantic grouping of interfaces/attributes gets lost, unless we enhance autodoc to re-introduce this no matter the order in the IDL file. Be it. Better than nothing ... http://www.openoffice.org/issues/process_bug.cgi for the records. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[udk-dev] Re: [udk-cvs] CVS update [cws_src680_obo10]: /udk/idlc/inc/idlc/idlctypes.hxx
[EMAIL PROTECTED] wrote:
Tag: cws_src680_obo10
User: obo
Date: 2007-08-21 06:58:59+
Modified:
udk/idlc/inc/idlc/idlctypes.hxx
Log:
#i75046# windows 64bit remove dependency to stlport
Hi Oliver,
Please apply the attached simplifying patch to idlc before doing your
64bit-sans-stlport changes in idlc/inc/idlc/idlctypes.hxx and
idlc/inc/idlc/options.hxx. That way, there is one less string hash
functor definition to #ifdef.
Thanks,
-Stephan
Index: inc/idlc/idlctypes.hxx
===
RCS file: /cvs/udk/idlc/inc/idlc/idlctypes.hxx,v
retrieving revision 1.6
diff -u -p -r1.6 idlctypes.hxx
--- inc/idlc/idlctypes.hxx 7 Sep 2005 18:04:36 - 1.6
+++ inc/idlc/idlctypes.hxx 21 Aug 2007 07:31:37 -
@@ -42,6 +42,9 @@
#include vector
#include set
+#ifndef _RTL_STRING_HXX_
+#include rtl/string.hxx
+#endif
#ifndef _SAL_TYPES_H_
#include sal/types.h
#endif
@@ -49,33 +52,9 @@
#include rtl/ustring.hxx
#endif
-struct EqualString
-{
- sal_Bool operator()(const ::rtl::OString str1, const ::rtl::OString str2) const
- {
- return (str1 == str2);
- }
-};
-
-struct HashString
-{
- sal_Int32 operator()(const ::rtl::OString str) const
- {
-return str.hashCode();
- }
-};
-
-struct LessString
-{
- sal_Bool operator()(const ::rtl::OString str1, const ::rtl::OString str2) const
- {
- return (str1 str2);
- }
-};
-
typedef ::std::list ::rtl::OString StringList;
typedef ::std::vector ::rtl::OString StringVector;
-typedef ::std::set ::rtl::OString, LessString StringSet;
+typedef ::std::set ::rtl::OString StringSet;
class AstExpression;
typedef ::std::list AstExpression* ExprList;
@@ -85,7 +64,7 @@ typedef ::std::list AstUnionLabel*
class AstDeclaration;
-typedef ::std::hash_map ::rtl::OString, AstDeclaration*, HashString, EqualString DeclMap;
+typedef ::std::hash_map ::rtl::OString, AstDeclaration*, ::rtl::OStringHash DeclMap;
typedef ::std::list AstDeclaration* DeclList;
class AstScope;
Index: inc/idlc/options.hxx
===
RCS file: /cvs/udk/idlc/inc/idlc/options.hxx,v
retrieving revision 1.3
diff -u -p -r1.3 options.hxx
--- inc/idlc/options.hxx 7 Sep 2005 18:05:11 - 1.3
+++ inc/idlc/options.hxx 21 Aug 2007 07:31:37 -
@@ -42,8 +42,7 @@
typedef ::std::hash_map ::rtl::OString,
::rtl::OString,
- HashString,
- EqualString OptionMap;
+ ::rtl::OStringHash OptionMap;
class IllegalArgument
{
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] swf filter - where to get?
Claudio Alberto Andreoni wrote: Hello everybody, sorry for being there again asking for help. does anybody know how to compose the chain for generating a swf from a XComponent, which is produced out of a XDrawPage? I had a look at the com.sun.star.drawing.GraphicExportFilter, but that service does not support any useful MIME for that purpose. I also considered com.sun.star.Impress.FlashExportDialog but, apart from looking a lot like a graphical widget it seems not to be able to perform such a job. SWFFliter and SWFExporter, which are the main classes involved in the process, should be part of some XMultiServiceFactory-retrievable service, shouldn't they? [EMAIL PROTECTED] is probably a better place for a question like this about using the OOo UNO API. I would suggest you retry there. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Unpublished interface to published service
Kohei Yoshida wrote: To be honest, I didn't know there was such a thing as a new style service. Is there any article, or web page that I can read about how to create a new style UNO service? http://marketing.openoffice.org/ooocon2004/presentations/friday/shinyhappyuno.pdf presented things like new style services to the world. The Developer's Guide at http://api.openoffice.org/DevelopersGuide/DevelopersGuide.html contains further information. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] modifying UNO struct and binary compatibility
Kohei Yoshida wrote: On Tue, 2007-07-17 at 15:38 +0200, Stephan Bergmann wrote: Kohei Yoshida wrote: Since the size of the TableFilterFiled as well as the data members and their order will not change before and after the change, I would think it's safe to make this change, but is it not safe? I appreciate your input. Your reasoning might be valid for C++, but remember that there are more language bindings for UNO. Thanks for your input. But I would still think that C++ is probably the pickest of all the languages UNO has bindings for, especially when it comes to ABI compatibility. In other words, the other languages are probably more relaxed about the change I was considering above. Then another killer: Even if it would work that new producers now produce enlarged struct instances and old consumers can still read them, it would not work that old producers produce original struct instances and new consumers expect to read them as enlarged ones. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] modifying UNO struct and binary compatibility
Kohei Yoshida wrote:
Hi there,
When I modify an existing struct in its idl and re-build the offapi
module, the buidl fails because of binary incompatible change.
But when I create a parent struct, and make the existing struct a
subclass of the new parent struct, and move some of the data members
from the original struct to the new parent struct, the build also fails
due to binary incompatible change.
But is that really the case? For instance, here is the original struct
I'm attempting to modify:
struct TableFilterField
{
com::sun::star::sheet::FilterConnection Connection;
long Field;
com::sun::star::sheet::FilterOperator Operator;
boolean IsNumeric;
double NumericValue;
string StringValue;
};
by moving the first two data members into the new base struct, here is
the change I want to make:
/** New base struct */
struct TableFilterFieldBase
{
com::sun::star::sheet::FilterConnection Connection;
long Field;
};
/** Modified original struct. */
struct TableFilterField: TableFilterFieldBase
{
com::sun::star::sheet::FilterOperator Operator;
boolean IsNumeric;
double NumericValue;
string StringValue;
};
Since the size of the TableFilterFiled as well as the data members and
their order will not change before and after the change, I would think
it's safe to make this change, but is it not safe?
I appreciate your input.
Your reasoning might be valid for C++, but remember that there are more
language bindings for UNO.
-Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Relative Mouse Pointer Position
Neufeld Computer Services wrote: I am working on a macro in Draw, mostly as an exercise in learning OO Basic (migrating my brain from VBA) with Draw, and I want to discover and report the current position of the mouse relative to the DrawPage. I have been unable to locate any way to do this. Can someone point me to the right documentation? Is this possible? Things like this are more typically discussed at [EMAIL PROTECTED] Maybe you get more answers there (in case you still need any)... -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[udk-dev] Re: [udk-cvs] CVS update: /udk/www/java/man/types.html
[EMAIL PROTECTED] wrote: User: kr Date: 2007-06-20 15:02:17+ Modified: udk/www/java/man/types.html Log: moved into the wiki (http://wiki.services.openoffice.org/wiki/Uno/Java/Specifications/Type_Mapping) And all the carefully done formatting (incl. relevant one like 2SUP15/SUP - 215) is lost. :( -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Re: [udk-cvs] CVS update [cws_src680_bunoexttm]: /udk/cppu/inc/cppu/helper/purpenv/, /udk/cppu/source/helper/purpenv/, /udk/cppu/util/
Stephan Bergmann wrote:
[EMAIL PROTECTED] wrote:
File [added]: uno_purpenvhelpergcc3.map
Url:
http://udk.openoffice.org/source/browse/udk/cppu/util/uno_purpenvhelpergcc3.map?rev=1.1.2.1content-type=text/vnd.viewcvs-markup
Added lines: 32
---
UDK_3_0_0 {
global:
GetVersionInfo;
[...]
File [added]: uno_purpenvhelperC52.map
Url:
http://udk.openoffice.org/source/browse/udk/cppu/util/uno_purpenvhelperC52.map?rev=1.1.2.1content-type=text/vnd.viewcvs-markup
Added lines: 35
---
UDK_3_0_0 {
global:
GetVersionInfo;
_DYNAMIC;
_GLOBAL_OFFSET_TABLE_;
_PROCEDURE_LINKAGE_TABLE_;
1 You should not include _DYNAMIC, _GLOBAL_OFFSET_TABLE_,
_PROCEDURE_LINKAGE_TABLE_ in the Solaris mapfile; the linker treats them
specially, anyway.
2 Do we want that GetVersionInfo stuff? (It appears some mapfiles
export it, others don't.) What was it good for again?
3 See http://udk.openoffice.org/common/man/apicppclasses.html: if
your classes are designed properly, it should never be necessary to
export vtable symbols (like _ZTVN4cppu6helper7purpenv4BaseE and
__1cEcppuGhelperHpurpenvEBaseG__vtbl_).
-Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Re: [udk-cvs] CVS update [cws_src680_bunoexttm]: /udk/cppu/inc/cppu/helper/purpenv/, /udk/cppu/source/helper/purpenv/, /udk/cppu/util/
Kay Ramme - Sun Germany - Hamburg wrote:
Hi Stephan,
Stephan Bergmann wrote:
[EMAIL PROTECTED] wrote:
File [added]: uno_purpenvhelpergcc3.map
Url:
http://udk.openoffice.org/source/browse/udk/cppu/util/uno_purpenvhelpergcc3.map?rev=1.1.2.1content-type=text/vnd.viewcvs-markup
Added lines: 32
---
UDK_3_0_0 {
global:
GetVersionInfo;
[...]
File [added]: uno_purpenvhelperC52.map
Url:
http://udk.openoffice.org/source/browse/udk/cppu/util/uno_purpenvhelperC52.map?rev=1.1.2.1content-type=text/vnd.viewcvs-markup
Added lines: 35
---
UDK_3_0_0 {
global:
GetVersionInfo;
_DYNAMIC;
_GLOBAL_OFFSET_TABLE_;
_PROCEDURE_LINKAGE_TABLE_;
1 You should not include _DYNAMIC, _GLOBAL_OFFSET_TABLE_,
_PROCEDURE_LINKAGE_TABLE_ in the Solaris mapfile; the linker treats
them specially, anyway.
OK, I do so. We should probably remove that from the cppuhelper map
files as well ...
Yes, pvs -s libuno_cppuhelperC52.so.3 shows that those lines in
cppuhelper/source/cc5_solaris_psarc.map:1.15 are ignored and bogus.
2 Do we want that GetVersionInfo stuff? (It appears some mapfiles
export it, others don't.) What was it good for again?
Actually I think, this is kind of useless anyway (-MH: any comments on
this?). Can also be found in cppuhelper, but removing it would probably
be incompatible, wouldn't it?!
Removing it from an existing mapfile would strictly speaking be
incompatible, yes. However, not adding it to a (new) mapfile is another
story, of course.
-Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[udk-dev] [Fwd: [udk-cvs] CVS update [cws_src680_bunoexttm]: /udk/ure/prj/]
Kay, Why would ure depend on cli_ure? The only build actions in module ure are to copy and zip some files from the ure module itself, see ure/source/makefile.mk:1.4; no need for cli_ure I could make out. -Stephan Original Message Subject: [udk-cvs] CVS update [cws_src680_bunoexttm]: /udk/ure/prj/ Date: 16 Feb 2007 18:21:06 +0100 From: [EMAIL PROTECTED] Reply-To: dev@udk.openoffice.org Organization: StarOffice / Sun Microsystems, Inc. To: [EMAIL PROTECTED] Newsgroups: openoffice.udk.cvs Tag: cws_src680_bunoexttm User: kr Date: 2007/02/16 09:21:02 Modified: udk/ure/prj/build.lst Log: fixed: moved dependency from odk module to ure module File Changes: Directory: /udk/ure/prj/ File [changed]: build.lst Url: http://udk.openoffice.org/source/browse/udk/ure/prj/build.lst?r1=1.1r2=1.1.30.1 Delta lines: +1 -1 --- --- build.lst 26 May 2005 10:01:01 - 1.1 +++ build.lst 16 Feb 2007 17:21:00 - 1.1.30.1 @@ -1,2 +1,2 @@ -ur ure : solenv NULL +ur ure : cli_ure solenv NULL ur ure\source nmake - all ur_source NULL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[udk-dev] Re: [udk-cvs] CVS update [cws_src680_macosxmapfiles]: /udk/jvmaccess/util/
[EMAIL PROTECTED] wrote:
Tag: cws_src680_macosxmapfiles
User: tra
Date: 2007/01/12 02:49:00
Modified:
udk/jvmaccess/util/gcc3_linux_intel.map
Log:
#i69351# remove not existing symbols from map file
This is wrong, see gcc3_linux_intel.map:1.8: #i38188# different symbols
are required for gcj, maybe a different less fragile long-term solution
is required here
Please revert,
-Stephan
File Changes:
Directory: /udk/jvmaccess/util/
===
File [changed]: gcc3_linux_intel.map
Url:
http://udk.openoffice.org/source/browse/udk/jvmaccess/util/gcc3_linux_intel.map?r1=1.11r2=1.11.32.1
Delta lines: +3 -5
---
--- gcc3_linux_intel.map7 Sep 2005 19:23:45 - 1.11
+++ gcc3_linux_intel.map12 Jan 2007 10:48:57 - 1.11.32.1
@@ -4,9 +4,9 @@
#
# $RCSfile: gcc3_linux_intel.map,v $
#
-# $Revision: 1.11 $
+# $Revision: 1.11.32.1 $
#
-# last change: $Author: rt $ $Date: 2005/09/07 19:23:45 $
+# last change: $Author: tra $ $Date: 2007/01/12 10:48:57 $
#
# The Contents of this file are made available subject to
# the terms of GNU Lesser General Public License Version 2.1.
@@ -60,8 +60,6 @@
_ZN9jvmaccess14VirtualMachine11AttachGuard17CreationExceptionD1Ev; #
jvmaccess::VirtualMachine::AttachGuard::CreationException::~CreationException()
_ZN9jvmaccess14VirtualMachine11AttachGuard17CreationExceptionD2Ev; #
jvmaccess::VirtualMachine::AttachGuard::CreationException::~CreationException()
_ZN9jvmaccess14VirtualMachineC2EP7JavaVM_ibP7JNIEnv_; #
jvmaccess::VirtualMachine::VirtualMachine(JavaVM *, int, bool, JNIEnv *)
-_ZN9jvmaccess14VirtualMachineC1EP10_Jv_JavaVMibP10_Jv_JNIEnv; #
jvmaccess::VirtualMachine::VirtualMachine(JavaVM *, int, bool, JNIEnv *)
-_ZN9jvmaccess14VirtualMachineC2EP10_Jv_JavaVMibP10_Jv_JNIEnv; #
jvmaccess::VirtualMachine::VirtualMachine(JavaVM *, int, bool, JNIEnv *)
} UDK_3.1;
UDK_3.3 {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[udk-dev] Re: [udk-cvs] CVS update [cws_src680_macosxmapfiles]: /udk/cppuhelper/source/
[EMAIL PROTECTED] wrote: Tag: cws_src680_macosxmapfiles User: tra Date: 2007/01/11 00:45:20 Modified: udk/cppuhelper/source/gcc3_linux_intel.map udk/cppuhelper/source/makefile.mk Log: #69351#support for exported symbols lists as replacement for missing map file support on Mac OS X File Changes: Directory: /udk/cppuhelper/source/ == File [changed]: gcc3_linux_intel.map Url: http://udk.openoffice.org/source/browse/udk/cppuhelper/source/gcc3_linux_intel.map?r1=1.11r2=1.11.70.1 Delta lines: +1 -1 --- --- gcc3_linux_intel.map27 Oct 2005 17:19:16 - 1.11 +++ gcc3_linux_intel.map11 Jan 2007 08:45:18 - 1.11.70.1 @@ -118,7 +118,7 @@ _ZN4cppu22createComponentContextEPKNS_17ContextEntry_InitElRKN3com3sun4star3uno9ReferenceINS6_17XComponentContextEEE; _ZN4cppu22getImplHelperInitMutexEv; _ZN4cppu23WeakImplHelper_getTypesEPNS_10class_dataE; -_ZN4cppu23bootstrapInitialContextERKN3com3sun4star3uno9ReferenceINS2_4lang22XMultiComponentFactoryEEERKNS4_INS2_8registry15XSimpleRegistryEEESE_RKN3rtl8OUStringE; +_ZN4cppu23bootstrapInitialContextERKN3com3sun4star3uno9ReferenceINS2_4lang22XMultiComponentFactoryEEERKNS4_INS2_8registry15XSimpleRegistryEEESE_RKN3rtl8OUStringERKNSF_9BootstrapE; Looking at this, I think the original, wrong line for bootstrapInitialContext was an error and should go completely: bootstrapInitialContext is a cppuhelper-local function and should not be exported (neither cc5_solaris_sparc.map nor msvc_win32_intel.map export it, and gcc3_linux_intel.map effectively does not export it either, due to the misspelling). Tino, please fix by taking the line out completely. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] cpp uno: Enhancement for uno::Reference
Thorsten Behrens wrote: Stephan Bergmann [EMAIL PROTECTED] writes: That is, from my side: go ahead. Hi Stephan, all, well, finally got around doing just that. Issue http://www.openoffice.org/issues/show_bug.cgi?id=72499 contains a patch, that adds said functionality, and addresses a few ambiguities/incomplete types across OOo. Thorsten, I saw your patch yesterday and only had a quick glance at it. What I do not understand is whether those few ambiguities/incomplete types across OOo are related to the Reference change (i.e., whether the Reference change introduces an incompatibility that has to be taken care of at those various places across OOo---that would be a clear no no). -Stephan Any objections, or shall I proceed? Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] cpp uno: Enhancement for uno::Reference
Thorsten Behrens wrote: Stephan Bergmann [EMAIL PROTECTED] writes: I saw your patch yesterday and only had a quick glance at it. What I do not understand is whether those few ambiguities/incomplete types across OOo are related to the Reference change (i.e., whether the Reference change introduces an incompatibility that has to be taken care of at those various places across OOo---that would be a clear no no). Hi Stephan, no, this ain't an incompatibility in the sense of the word, although without the changes, compilation would break. Basically, removing operator const Reference XInterface unearthes various places, where the source type (that of the referenced interface being implicitely casted) is incomplete, or where the conversion to XInterface is ambiguous (people who do multiple inheritance). The former borders to a bug, the latter is inconvenient - although I suspect that the underlying reason for people passing around generic XInterfaces (and later querying for the actually needed one again) is at least partially related to uno::Reference having _only that one_ single automatic conversion in the past. So it *is* an incompatible change (correct code that did compile now fails to compile). I could live with the consequences of this change, however. -Stephan Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] cpp uno: Enhancement for uno::Reference
Thorsten Behrens wrote: Stephan Bergmann [EMAIL PROTECTED] writes: I saw your patch yesterday and only had a quick glance at it. What I do not understand is whether those few ambiguities/incomplete types across OOo are related to the Reference change (i.e., whether the Reference change introduces an incompatibility that has to be taken care of at those various places across OOo---that would be a clear no no). Hi Stephan, no, this ain't an incompatibility in the sense of the word, although without the changes, compilation would break. Basically, removing operator const Reference XInterface unearthes various places, where the source type (that of the referenced interface being implicitely casted) is incomplete, or where the conversion to XInterface is ambiguous (people who do multiple inheritance). The former borders to a bug, the latter is inconvenient - although I suspect that the underlying reason for people passing around generic XInterfaces (and later querying for the actually needed one again) is at least partially related to uno::Reference having _only that one_ single automatic conversion in the past. Cheers, -- Thorsten To avoid problems with places where an otherwise ambiguous upcast from XWhatever to XInterface (i.e., where XWhatever uses multiple inheritance) used to work via the removed Reference::operator, would it make sense to specialize the new copy constructor/operator = member templates for the special case Ifc=XInterface? Just a thought. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] getString() for com.sun.star.text.XText fails to return properly with JDK 1.6.0-beta2
synfin wrote: Hello, I'm working on a program that simply extracts the body of text from .odt and .doc files as a String. The snippet of code below either prints the entire document or simply a blank line, which seems to be dependent on the length of the document. That is, after passing a certain length (44 pages), the program will no longer output anything besides a blank line. Could anyone please lend me some insight? I'm also open to other (better) ways to extract a simple string from any document. Thank you. Kind regards, Josh Josh, For questions like this concerning the OOo API I guess you can find more help over at [EMAIL PROTECTED] (One thing that comes to mind is that much of the OOo code internally uses a string type (C++ tools String) that can only handle strings of less than 64K characters. That might be the reason you get an empty string for a long document.) -Stephan P.S. How can I enable debugging output from soffice.bin? CODE XComponent openDocument = openDocument(documentProperties); // Query its XTextDocument interface to get the text scrapeDoc = (XTextDocument)UnoRuntime.queryInterface( XTextDocument.class, openDocument); XText scrapeText = scrapeDoc.getText(); // Print body of text to stdout System.out.println(scrapeText.getString()); /CODE - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Problems in running openoffice.org 2.0 with xvfb-run and oood
Marco Bizzarri wrote: Hi all. I'm trying to run openoffice.org 2.0 on a slackware based distribution. I'm running into a strange problem: the openoffice daemon (oood) starts and spawns the correct number of instances, but, soon after, the openoffice.org dies, without being restarted by oood. I tryied to raise the logging level in oood, but it was useless.. How can I log what is going on in the starting of OOo ? Regards Marco Marco, How did you obtain your version of OOo? The official OOo (available as source or installation sets from http://www.openoffice.org/) to my knowledge does not have an openoffice daemon (oood). I assume it is part of your slackware based distribution. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[udk-dev] Removed dead stuff from URP
As part of CWS sb23, I removed some dead stuff from the UNO Remote Protocol (URP): - The special messages acquire and getProperties. - The properties BridgeId, SupportedVersions, SupportsMultipleSynchronous, TypeCacheSize, OidCacheSize, TidCacheSize, Version, FlushBlockSize, OnewayTimeoutMUSEC, ForceSynchronous, ClearCache. (There should not be any situations where any of that stuff has actually been used, so the change is ok.) See http://www.openoffice.org/issues/show_bug.cgi?id=35277 and http://udk.openoffice.org/common/man/spec/urp.html. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Re: Addon with modal dialog
Andreas Saeger wrote: Stephan Bergmann wrote: Andreas, I guess dev@api.openoffice.org is a better mailing list for this question. Please try and repost there. -Stephan Sorry, I am confused by too many new concepts and acronyms. No problem. Just wanted to make sure you get lots of meaningful answers (and I guessed chances would be higher on the other list, read by more/different people). -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Addon with modal dialog
Andreas, I guess dev@api.openoffice.org is a better mailing list for this question. Please try and repost there. -Stephan Andreas Saeger wrote: I use the Addons.xcu provided at http://wiki.services.openoffice.org/wiki/UNO_component_packaging without node oor:name=Images and replaced the python-class with my own one: import uno import unohelper import string from com.sun.star.task import XJobExecutor class Wavelet( unohelper.Base, XJobExecutor ): cnt = 0 def __init__( self, ctx ): Wavelet.cnt +=1 self.ctx = ctx def __del__(self): Wavelet.cnt -=1 def trigger( self, args ): Dlg = self.ctx.ServiceManager.createInstance(com.sun.star.awt.UnoControlDialog) M = self.ctx.ServiceManager.createInstance(com.sun.star.awt.UnoControlDialogModel) M.Title = args.__repr__() +' '+ str(Wavelet.cnt) +'' Dlg.setModel(M) Dlg.setVisible(True) Dlg.execute() g_ImplementationHelper = unohelper.ImplementationHelper() g_ImplementationHelper.addImplementation( Wavelet, name.vojta.openoffice.Wavelet, (com.sun.star.task.Job,),) It executes a most simple awt-dialog, showing a reference-counter and the content of the trigger's second param args in the title. (could not imagine which args are passed. It's the param execute of the control's URL service:name.vojta.openoffice.Wavelet?execute) After installation with package manager of OOo2.0.2(Linux) I can open a series of new writer docs, call the modal dialog from unnamed1, another instance from unnamed2,... After closing one dialog I can access the respective document-view again. Everything works as expected, BUT: All instances of the dialogs are stacked. I can access the last opened dialog only. Another python-addon oooblogger behaves likewise. Calc's C++ solver is non-modal and I guess it uses awt.TopWindow rather than UnoControlDialog. I translated some working basic-code to python because I wanted an object orientated implementation. It includes dialog-classes for selection and navigation across different types of spreadsheet-cells. Because my dialogs start with some user-selection and perform selection and scolling within the current controller they should be modal in respect to the current controller, but they should allow parallel inspection of two views as well. So they should not be modal in respect to each other. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] StarBasic Kill statement
Paolo Mantovani wrote: again,sorry for the (totally unwanted) misunderstanding No problem. I was in a bit of a hurry yesterday so did not read your mails too carefully. Anyway, I meanwhile asked Basic expert Andreas Bregas to have a look at these two threads and give helpful comments. -Stephan regards Paolo M - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] cpp uno: Enhancement for uno::Reference
Thorsten Behrens wrote: Stephan writes: I vaguely remember having discussed this before with Daniel Bölzle, but neither of us can remember whether there were any serious problems with it. Well, will of course try this on a full build ;-) Whether or not the constructor should be explicit might be a question of style, however. Don't think so. To match behaviour of plain ptrs (for the implicit conversion), the copy constructor needs to be non-explicit. After all, having that taking place automatically is my whole point here. I do not think that the situation is that simple. In my opinion, there are three possibilities, not two: First, the current situation where you have to use the potentially expensive ReferenceXBase(xDerived,UNO_QUERY_THROW) or the non-obvious, abstraction-breaking xDerived.get() or ReferenceXBase(xDerived.get()) to up-cast from XDerived to XBase. Second, the explicit option where you have to use the explicit ReferenceXBase(xDerived) for the up-cast. Third, the implicit option you proposed where you can implicitly use xDerived for the up-cast. That the third most closely mimics plain pointers does not automatically qualify it as the best solution. Too much implicit conversion can make code too obscure and fragile, as we probably all have learned the hard way. -Stephan [...] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] cpp uno: Enhancement for uno::Reference
Thorsten Behrens wrote: Stephan Bergmann [EMAIL PROTECTED] writes: Third, the implicit option you proposed where you can implicitly use xDerived for the up-cast. That the third most closely mimics plain pointers does not automatically qualify it as the best solution. Too much implicit conversion can make code too obscure and fragile, as we probably all have learned the hard way. This statement is as true in general as is doesn't apply to this case. The only thing the proposed change will facilitate is the implicit upcast a naked ptr-to-interface has offered since ages. All of us should be used to that behaviour, have employed it countless times, and found it convenient (I for myself did, at least). This is in no way comparable to e.g. the automatic conversions of ints to strings, where semantics really get obscured. As I wrote before, I consider this kind of a style issue in this case and could probably live with both solutions. That is, from my side: go ahead. -Stephan Cheers, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] StarBasic Kill statement
Paolo Mantovani wrote: Hi all, The kill statement in StarBasic can delete entire folders Calling OptionCompatible(True) before does not affect the behavior. ( OOo 2.0.2 ) The documentation doesn't say explicitly that it shouldn't happen but anyway it speaks only of files, and never of folders. Furthermore, there is a specific statement to delete directories ( RmDir ) In VBA if you try to kill a directory you get an error (file not found) so I think that this is a compatibility issue. any comments? Is this intended as a follow up to http://udk.openoffice.org/servlets/ReadMsg?list=devmsgNo=3564? If yes, why do you start a new thread? And why don't you instead answer my question where exactly in the OOo CVS the line If oUcb.Exists(FilePath) Then (that you claim should be changed) is located, so I can tell you which OOo project would be appropriate where to re-post your mail or file an issue? (As udk most probably is not the appropriate project.) -Stephan thanks Paolo M - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[udk-dev] Re: [udk-cvs] CVS update [cws_src680_qiq]: /udk/cppuhelper/source/
Frank, please add the newly exported symbol to the correct section (see http://udk.openoffice.org/common/man/libraryversioning.html Adding an Exported Symbol). Also note http://udk.openoffice.org/common/man/apicppclasses.html, (7), third bullet. Thanks, -Stephan [from [EMAIL PROTECTED]:] [EMAIL PROTECTED] wrote: Tag: cws_src680_qiq User: fs Date: 2006/06/30 01:01:57 Modified: udk/cppuhelper/source/cc5_solaris_sparc.map Log: need RTTI information for OweakObject for #i51143# File Changes: Directory: /udk/cppuhelper/source/ == File [changed]: cc5_solaris_sparc.map Url: http://udk.openoffice.org/source/browse/udk/cppuhelper/source/cc5_solaris_sparc.map?r1=1.14r2=1.14.38.1 Delta lines: +1 -0 --- --- cc5_solaris_sparc.map 27 Oct 2005 17:18:55 - 1.14 +++ cc5_solaris_sparc.map 30 Jun 2006 08:01:54 - 1.14.38.1 @@ -277,6 +277,7 @@ __1cEcppuGUnoUrlNgetConnection6kM_rkn0AQUnoUrlDescriptor__; __1cEcppuGUnoUrlLgetProtocol6kM_rkn0AQUnoUrlDescriptor__; __1cEcppuGUnoUrlNgetObjectName6kM_rknDrtlIOUString__; +__1cEcppubC__RTTI__1nEcppuLOWeakObject__; local: *; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] New media types for extensions
Frank Schönheit - Sun Microsystems Germany wrote: Hi Joachim, this was only an example. Meanwhile I favour the idea of a new file extension for extensions. which means somebody can rename a new extension, requiring license acceptance, to an old extension, and then run it without licence acceptance in 2.0.3. Is this desired? See this thread at [EMAIL PROTECTED] for a discussion of why changing anything in manifest.xml does not help here, anyway (.zip). -Stephan Also, aren't extensions to weak to distinguish file content? Ciao Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Private UNO API for Integrated components
Kohei Yoshida wrote: On 5/30/06, Stephan Bergmann [EMAIL PROTECTED] wrote: Kohei Yoshida wrote: Hi all, I was hoping that someone on this list could help me out on this. Here is what I'm trying to do. I have a top level module called 'scsolver' which provides an optimization solver component for Calc (or just 'Solver' for short). You don't see this in the upstream build since this module is still ooo-build only, just in case you're wondering. In this module, I need to include a set of new, private UNO IDLs to glue the main Solver component with an external optimization library. Both the main component and the external component need to be able to use these UNO interfaces, which means that, somehow the source files in this module need to be able to find the header files (*.hpp) that are generated from my IDLs. The external library, for now, will remain inside the scsolver module. So, how do I go about defining my private IDLs at module level, without adding them to the master list used by the entire OO.o source tree? I've check the source, and the chart2 module may have done something similar, but I'm not entirely sure how it's done. The by far easiest approach would be to do add your UNOIDL entities to CVS module offapi, but to not mark them as published so that they can change over time if there is a need (you might also want to add some comment that those are private entities that are not intended to be published at all, and you might want to choose some appropriately named UNOIDL module for them). That way, you do not need to fiddle with the details of cppumaker, and your UNO types are readily available in every UNO environment (Java, CLI, etc.) where you might need them in the future. Thanks for your advice Stephan. I'll follow your advice and add IDLs to offapi. By the way, the APIs I intend to use as a glue will be private for now, but I want them to eventually get published once they stabilize, so that other people can easily add new backend algorithms with much ease. Also, is there a way to export multiple services from a single shared library? I need to export two, or possibly more services, but I'd rather keep them in a single shared library because those services will be tightly coupled. Or can each shared library only export one service? There can be any number of services in one shared library. See stoc/source/uriproc/component.cxx:1.4 for an example of how I organize four services into one shared library (note that, over time, various idioms and helpers have emerged for this, so other examples may look rather different). -Stephan Thanks, Kohei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] A request for com.sun.star.lang.XEventListener
Rony G. Flatscher wrote:
Hi Kay,
Rony,
Thanks for the detailed explanation of why XEventListener should extend
java.util.EventListener. Doing so would not be difficult, I just
hesitated to add such (at first sight arbitrary) special casing (and
then simply forgot about your request). Please file an issue for me,
and I can probably add that for OOo 2.0.3.
-Stephan
according to the documentation com.sun.star.lang.XEventListener
does not report to implement the Java interface
java.util.EventListener. It seems that java.beans.Introspector is
not able to identify/locate the OOo EventListeners breaking generic
reflective code as a result.
what would be the advantage of the Introspector being able to identify
event listeners?
Every Java program relying on the abliity of the Introspector to
identify event listeners will be able to rely on the OOo Java interfaces
as well. Or put differently: every Java code breaks with OOo Java event
listeners, because OOo does not classify its event listeners of type .
What would the usage scenario look like? Do you have an example at hand?
Yes, I think so. An (rather important) example might be:
http://jakarta.apache.org/bsf
The Bean Scripting Framework (BSF) is a Java opensource framework
allowing Java programs to easily invoke scripts in non-Java languages
and also supplies functionality to non-Java scripting engines to
interface with Java. This way non-Java programs are able to interface
and take advantage of Java.
I have been using BSF to allow the free, opensource, multiplatform
scripting language ooRexx (cf. http://www.ooRexx.org) to drive OOo via
Java. (The generic support for this ooRexx-to-Java bridge is dubbed
BSF4Rexx and will get contain the generic support for OOo, making it
considerably easy for script coders to drive OOo in a platform
independent manner.)
[You can take a look at the following work:
http://wi.wu-wien.ac.at/rgf/diplomarbeiten/BakkStuff/2005/200511_OOo-Ahammer/200511_OOoAutomation.pdf
which contains nutshell examples of driving OOo from ooRexx, showing the
code and images of the resulting OOo window. All examples run under
Linux *and* Windows, with the exception of the MS Access sample, of
course. This work was updated in 2006-11. There is another student who
is about to finalize another work, creating nutshell examples of using
ooRexx as a macro language for OOo 2.x.]
With the advent of OOo 2.0 a Java based scripting framework is
available, which I use to plug in ooRexx into OOo, allowing it to be
used as a scripting language beside OOo Basic, Python, JavaScript
(Rhino), BeanShell. (It would be now a matter of a few minutes to add
all the BSF supported scripting languages using the ooRexx
implementation as a template. Will announce that fact, once the ooRexx
implementation goes Golden) Just to give you an idea about the
complexity of this part of the task (besides getting acquainted with
the OOo scripting framework itself), here is the necessary code to make
ooRexx available as a macro language to OOo:
--- cut here --
ScriptSourceModel.invoke(...):
// ... cut ...
BSFManager mgr = new BSFManager();
Vector args= new Vector(aParams.length+1);
try // create arguments for ooRexx
{
int i;
// rgf, make XScriptContext available to script
// 2006-01-06, set entries into BSF registry for retrieval by invoked
Rexx script (available in every Rexx scope)
mgr.registerBean(ScriptProviderForooRexx.OOREXX_XSCRIPTCONTEXT_KEY,
ScriptContext.createContext(m_xModel, m_xContext, m_xMultiComponentFactory));
mgr.registerBean(ScriptProviderForooRexx.OOREXX_VERSION_KEY,1.0);
// add arguments to Vector
for (i=0;iaParams.length;i++)
{
args.addElement(aParams[i]);// add argument
}
}
// ... cut (plain vanilla stuff from ScriptSourceModel.invoke(...) ...
result=mgr.apply(ScriptProviderForooRexx.OOREXX_BSFLANGUAGE,
OOo.ScriptProviderForooRexx, 0, 0, source, null, args);
if (result == null)
{
return new Any(new Type(), null);
}
return result;
// ... cut ...
--- cut here --
Changing a few constants and you could use the same code for dispatching
JavaScript (Rhino), Jython, JLog (PROLOG) etc. via BSF and the OOo
scripting framework. (Just to hint at the importance of Java frameworks
like BSF.)
---
Now, because OOo event handlers do not declare to have the Java
java.util.EventListener implemented (it is actually just a
classification information, as it is an interface class not defining any
fields or methods), the generic event handler support of BSF breaks.
(Due to the opensourceness of BSF I was able to go through the
respective code and was able to add the support for OOo event handlers;
but this is a private fix, which I doubt that the BSF committers will
accept for the official distribution. If interested, you could look at
it at the URL
Re: [udk-dev] PyUNO: Unexpected connection closure
Andrew Z wrote: Thanks for the core tip: I didn't think of it. In fact, I did get a core with the following backtrace, so I should file a bug report in OOo? Yes, please file an issue (you can assign it to me, sb), and please include the detailed description of how to reproduce it. Thanks, -Stephan #0 0xb7597e20 in uno_type_isAssignableFromData () from /opt/openoffice.org2.0/program/libuno_cppu.so.3 #1 0xb759b9a8 in uno_type_isAssignableFromData () from /opt/openoffice.org2.0/program/libuno_cppu.so.3 #2 0xb75a30b7 in uno_type_any_assign () from /opt/openoffice.org2.0/program/libuno_cppu.so.3 #3 0xb4280f45 in component_getFactory () from /opt/openoffice.org2.0/program/acceptor.uno.so #4 0xb27eb22a in component_getFactory () from /opt/openoffice.org2.0/program/remotebridge.uno.so #5 0xb27d2f29 in component_canUnload () from /opt/openoffice.org2.0/program/liburp_uno.so #6 0xb27d09a4 in component_canUnload () from /opt/openoffice.org2.0/program/liburp_uno.so #7 0xb27c68d5 in component_canUnload () from /opt/openoffice.org2.0/program/liburp_uno.so #8 0xb73f02f7 in osl_yieldThread () from /opt/openoffice.org2.0/program/libuno_sal.so.3 #9 0x00d65b80 in start_thread () from /lib/libpthread.so.0 #10 0x00bd69ce in clone () from /lib/libc.so.6 Andrew Joerg Budischewski wrote: in general, OOo indeed crashes when you get an unexpected connection closure, please check, if you get a core. If OOo does not crash, it may also be possible, that the office terminates faster than it can put the reply for terminate on the wire. AFAIK the office does not wait for remote connections to be dropped before it terminates. If the latter is the case, this is difficult to fix. I'd try to ignore the disposed exception on terminate. Another (more complicated) workaround can be, that you implement a component inside the office, which does the terminate call on the desktop delayed (by creating an own thread that waits form some milliseconds), but that sounds overkill to me. Bye, Jörg Andrew Z wrote: Hello, I am having strange problems with PyUNO and OOo 2.0.1rc1 on Linux. In some situations, I get the following error on desktop terminate(): uno.com.sun.star.lang.DisposedException: URP_Bridge : disposed\n(tid=3) Unexpected connection closure Observations: - The unexpected closure happens reliably with Xvfb and on a warm start. - The closure does not happen with Xvfb on a cold start (first attempt). - The closure does not happen with Xvfb on a warm start if Python sleeps 2 seconds before terminate(). - The closure does not happen with a real X server. - Some documents do not cause the error (but observations above refer to a blank Word document). My simplified program simply opens OOo, opens a document, closes document, and closes OOo. The program, scripts for running it through Xvfb, and a sample document are here: http://narnia.dnsalias.org/ooo/uno-disconnect.zip (3.9KB) The purpose of the full version of my program is automating testing of OpenOffice.org itself, and unfortunately, the unexpected closure is the same error PyUNO gives when OpenOffice.org crashes. Is this unexpected closure problem the fault of OOo, PyUNO, or my program? How can it be fixed? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Java filter batch job
Martin Gallwey wrote: Thinking about the issue a little longer, I came to the following conclusion: 1 I still think it is bad to have C++ objects that implement UNO objects and do substantial things in their destructors, and that those implementations should ideally be fixed. Maybe when Kai Kay proceed further with their grand work on improving the multi-threaded behaviour of Office, they can catch some of these kinds of problems. The CrashFilter test case showed up at least 4 cases where the SolarMutex is locked in a destructor (SwXNumberingRules destructor, XMLRedlineImportHelper destructor, SfxBaseModel::removeEventListener ( Ref XEventListener ) and SfxBaseModel::removeEventListener ( Ref XDocEventListener )). It would be easy to improve the granularity of the mutex in the SwXNumberingRules destructor, but the others would require a little more work, and possibly are only the tip of the iceberg anyway! 2 GC within typical JVMs of today seems to be flawed in that a long-running finalize method can lead to OutOfMemoryError in cases where this could be avoidable. We can make UNO more robust against this problem, without unduly sacrificing performance: Asynchronously shift the execution of potentially long-running finalize methods (i.e., com.sun.star.bridges.jni_uno.JNI_proxy.finalize() and com.sun.star.lib.uno.bridges.java_remote.ProxyFactory.Handler.finalize()) into some extra thread (finalize is already called asynchronously, so delaying it a little further and moving it to yet another thread should cause no problems). I experimentally added a com.sun.star.lib.util.AsynchronousFinalizer and modified the two finalize methods mentioned previously, and afterwards your testcase runs fine (which also shows that the claim that one additional thread should be enough is right). The advantage of this solution is that it works for both the intra-process JNI bridge and the inter-process Java URP bridge. (Also, once JVMs have matured to be more robust against long-running finalize methdos, we can think of removing this hack again.) Sounds good. I think the reason that 1 extra finalizer thread didn't work for me was because I didn't make the second call above (com.sun.star.lib.uno.bridges.java_remote.ProxyFactory.Handler.finalize()) asynchronous also. One thing that did occur to me was that we could use the 'Concurrent Low Pause Collector' : http://java.sun.com/docs/hotspot/gc1.4.2/#4.4.%20The%20Concurrent%20Low%20Pause%20Collector|outline or the 'Throughput Collector' http://java.sun.com/docs/hotspot/gc1.4.2/#4.2.%20The%20Throughput%20Collector|outline However, both seem to only really work on multi-processor machines, with both still using a single thread to do the 'major' collections. Neither collector seems to change substantially between 1.4.2 and 1.5 either. If there are no objections, I will happily add this to CWS mtg1. Yes, please do. I will test it with the non-reduced test case. Done: bridges/source/jni_uno/java/com/sun/star/bridges/jni_uno/JNI_proxy.java 1.7.14.1 jurt/com/sun/star/lib/uno/bridges/java_remote/ProxyFactory.java 1.6.4.1 jurt/com/sun/star/lib/util/makefile.mk 1.9.8.1 jurt/com/sun/star/lib/util/AsynchronousFinalizer.java 1.1.2.1 -Stephan Thanks, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Java filter batch job
Joerg Budischewski wrote: [...] The java uno bridge need to create also a fresh thread for each release (or at least for each concurrent release). It can't be a single thread doing the releases, because this would end in the same problem. A single additonal thread is enough to avoid the deadlock (thread A needs more memory, and thus the finalizer thread, but the finalizer thread waits for a mutex locked by thread A). On top of that, since the amount of memory available to a JVM is finite, it is important to keep the number of reachable objects within a JVM small at every point in time. Whether adding a single thread or multiple threads in the given case helps achieve this goal better is not a matter of correctness, but a matter of fine tuning. IMO, the simplest approach should be tried first. Only if it is known to behave badly (i.e., lead to OutOfMemoryError) often enough a more complex approach should be tried. The simplest approach (call release synchronously from the finalizer thread) is known to deadlock. It is arguable whether that deadlock is due to an error in the bridge, or due to an error in the involved UNO object implementations. However, if we agree on the former, the next approach in terms of simplicity would be to have exactly one extra thread. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Java filter batch job
Kay Ramme - Sun Germany - Hamburg wrote: Stephan Bergmann wrote: Joerg Budischewski wrote: [...] The java uno bridge need to create also a fresh thread for each release (or at least for each concurrent release). It can't be a single thread doing the releases, because this would end in the same problem. A single additonal thread is enough to avoid the deadlock (thread A needs more memory, and thus the finalizer thread, but the finalizer thread waits for a mutex locked by thread A). That's what I said :-). On top of that, since the amount of memory available to a JVM is finite, it is important to keep the number of reachable objects within a JVM small at every point in time. Whether adding a single thread or multiple threads in the given case helps achieve this goal better is not a matter of correctness, but a matter of fine tuning. Don't understand, what would be the difference between one or multiple release threads? OutOfMemoryError in a JVM happens because (1) too many objects are reachable at a given point in time, or (2) the finalizer is blocked, so that otherwise reclaimable garbage piles up. The problem under discussion is 2. If we solve it by adding one or multiple threads, we may run into 1 in different ways (e.g., if we have only one thread to do the releases, that thread may block and its queue may grow too large; if we have multiple threads, it is unlikely that all of them block at the same time, etc.). IMO, the simplest approach should be tried first. Only if it is known to behave badly (i.e., lead to OutOfMemoryError) often enough a more complex approach should be tried. Like always :-) The simplest approach (call release synchronously from the finalizer thread) is known to deadlock. It is arguable whether that deadlock is due to an error in the bridge, or due to an error in the involved UNO object implementations. However, if we agree on the former, the next approach in terms of simplicity would be to have exactly one extra thread. [...] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Java filter batch job
Martin Gallwey wrote:
Hi Mathias,
Is there a work around or do I re-write my filter in C++ ?
I don't know. Before giving a judgement on that we should find out what
your problem is. :-)
In the second stack I sent yesterday, for the finalizer thread, the top
of the stack is:
sw680mi.dll!SwXTextDocument::setPropertyValue(const rtl::OUString
rPropertyName={...}, const com::sun::star::uno::Any aValue={...})
Line 1944 + 0x27C++
Which is:
void SwXTextDocument::setPropertyValue(const OUString rPropertyName,
const Any aValue)
throw( UnknownPropertyException, PropertyVetoException,
IllegalArgumentException,
WrappedTargetException,
RuntimeException)
{
::vos::OGuard aGuard(Application::GetSolarMutex());
Ie, it is blocked waiting for the SolarMutex. The dispatch thread locked
the SolarMutex long ago at SwXMLExport::exportDoc. So, essentially the
JVM garbage collection can't complete until the SwXMLExport::exportDoc
returns, which explains why it runs out of memory (causing
java.lang.OutOfMemoryError - jni_uno::BridgeRuntimeError - heap
corruption)- there is no garbage collection going on.
It would seem to me that locking the SolarMutex in the destructor of
XMLRedlineImportHelper is the cause of this problem - maybe we can find
a different solution for that doesn't involve setting properties back to
SwXTextDocument?
It seems that there is also an issue in how the jni_uno bridge recovers
from the jni_uno::BridgeRuntimeError, it should recover more gracefully
than with heap corruption. I will attempt to reduce the test case to
reproduce this.
Not sure whether the JNI--UNO bridge itself has any problems here. It
passes its internal BridgeRuntimeError to Java as a
com.sun.star.uno.RuntimeException
(Java_com_sun_star_bridges_jni_1uno_JNI_1proxy_dispatch_1call in
jni_java2uno.cxx). Would be interesting to see what exactly causes the
reported heap corruption, so a reduced test case would be great.
Does this seem like a workable theory?
Yes, sounds like you found the problem. :)
Thanks,
Martin
-Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Java filter batch job
Mathias Bauer wrote:
Martin Gallwey wrote:
In the second stack I sent yesterday, for the finalizer thread, the top
of the stack is:
sw680mi.dll!SwXTextDocument::setPropertyValue(const rtl::OUString
rPropertyName={...}, const com::sun::star::uno::Any aValue={...})
Line 1944 + 0x27C++
Which is:
void SwXTextDocument::setPropertyValue(const OUString rPropertyName,
const Any aValue)
throw( UnknownPropertyException, PropertyVetoException,
IllegalArgumentException,
WrappedTargetException,
RuntimeException)
{
::vos::OGuard aGuard(Application::GetSolarMutex());
Ie, it is blocked waiting for the SolarMutex. The dispatch thread locked
the SolarMutex long ago at SwXMLExport::exportDoc. So, essentially the
JVM garbage collection can't complete until the SwXMLExport::exportDoc
returns, which explains why it runs out of memory (causing
java.lang.OutOfMemoryError - jni_uno::BridgeRuntimeError - heap
corruption)- there is no garbage collection going on.
But why does that method not return? The waiting Finalizer thread alone
shouldn't be a problem because it isn't guaranteed even to work at any
particular time, so it can't also be a problem when it finishes.
From the stacks in one of Martin's postings, it looks like
SwXMLExport::exportDoc does a lot of computation (with the SolarMutex
acquired all the time, he sais), involving calls across the JNI--UNO
bridge. If those computations/JNI--UNO bridge calls need enough JVM
memory, and the (typically single-threaded!) JVM finalizer is blocked
(as it is from the stacks), the JVM can run out of memory, which in turn
can manifest in an OutOfMemoryError in the thread doing
SwXMLExport::exportDoc.
It would seem to me that locking the SolarMutex in the destructor of
XMLRedlineImportHelper is the cause of this problem - maybe we can find
a different solution for that doesn't involve setting properties back to
SwXTextDocument?
The destruction of the object *must* be guarded by the SolarMutex or
otherwise you would run into the problem Kay mentioned (possibility of
crashes because of race conditions). So we have to keep it (moreover: we
miss it on several other places as KK showed in their report!).
Do I understand correctly that you think that the blocked finalizer
thread leads to an out of memory condition? Then in my understanding
there is no hope because whatever solution we choose the garbage
collection never will happen while any other API call is processed
inside the OOo process.
Not in the general case, but only if the involved API call can stall the
involved dtor as in Martin's case. Which is bad design, btw...
An approach that might help is if release-calls across the JNI--UNO
bridge (and across other bridges like URP bridges) were done
asynchronously, so that the JVM finalizer thread would not be blocked.
-Stephan
@Kay: Is that correct?
Best regards,
Mathias
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Standalone UNO (URE)
Tim michals wrote: Is there a link to just download URE? Is this available? Now available at download.openoffice.org. Has there been any work on using Visual Studio express? Or Visual Studio 8? In what way? Using the C/C++ Compilers, Linkers etc. from those products should work. A tighter integration with those products (i.e., not using makefiles etc.) might be on the long-term wish-list for the SDK, but AFAIK nothing is going on in that direction at the moment. -Stephan -Original Message- From: Stephan Bergmann [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 11, 2005 3:01 AM To: dev@udk.openoffice.org Subject: Re: [udk-dev] Standalone UNO (URE) Tim michals wrote: When will a new release be made available? I would more then happy to help test the new releases or builds. I expect to have the OOo 2.0 (RC2) URE (i.e., URE 1.0) available on download.openoffice.org this week. I'm in process of trying to decide between several frameworks UNO (URE) being one of them. But I just need a framework, not OOo. Also, need to have framework in built in debug mode. To have a debug build, you need to build the URE yourself. Unfortunately, you currently need to follow the OOo build instructions, and in module instsetoo_native a URE installation set will fall out of the build process. This, of course, is a time consuming process, in that lots of OOo-specific modules not necessary for URE will also be built. If you only need specific modules with debug information, there should be mechanisms available (a downloadable, pre-built solver) to only re-build those modules; the build instructions on www.openoffice.org should help you there. -Stephan I've been using XPCOM, but would like to try out UNO also -Original Message- From: Ingo Schmidt [mailto:[EMAIL PROTECTED] Sent: Monday, October 10, 2005 4:25 AM To: dev@udk.openoffice.org; Stephan Bergmann Subject: Re: [udk-dev] Standalone UNO (URE) Hi Tim, I do not get Error 2701, but Error 2703. But nevertheless, the Windows URE installation set available at http://ftp.rediris.es/mirror/openoffice.org/developer/ure_1_0/ is a m118, which had an error that breaks the msi database. I do not know, why this broken installation set is available for download. There should be a more recent installation set as soon as possible because this bug is fixed for a long time. If you can use the Orca-Tool to edit the msi-database the problem is very easy to fix. The Orca-Tool is part of Installer SDK and can be downloaded for free from Microsoft. Please unpack the URE installation set by executing the exe-file. You are asked, where to unpack the installation set. In this directory you find a file ure10.msi. This is the msi-database that describes the installation set. Please open this file with the Orca-tool. Look into the table Directory (left column). There you find a directory name FontsFolder which has a defaultdir Fonts:. This is an incorrect name. Please change Fonts: to Fonts (without colon at the end). Then save the msi-Database and start the setup.exe in the local installation set again. Now it should work without problems. Regards Ingo Stephan Bergmann wrote: Tim Michals wrote: I donwnload the windows version and started the installer. URE_1.0_windows_install_en-US.exe 20-Jul-2005 14:42 6.0M A dialog box appeared with the following message: Internal Error 2701. Fontsfoler Is there some way to pull this from CVS and build this project? I would like to have all of the code comiled with debug on so I can use VS 2005 to trace the code. The code for URE is scattered all over the OOo CVS. The actual platform install sets are built in instsetoo_native. Maybe Ingo Schmidt can give a hint on what might be the reason for your specific problem. -Stephan This is on windows XP Service pack 2. The goal is to use UNO for a Windows/Linux project. thanks, tcmichals From: Alexandro Colorado [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: dev@udk.openoffice.org Subject: Re: [udk-dev] Standalone UNO (URE) Date: Fri, 30 Sep 2005 12:30:36 +0200 Tim Michals wrote: Is there a way to download and compile the UNO standalone? If not when? It was my understanding that it would be offered some time during OOo 2.0? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Yes any repository will have it, here is the one from RedIris. http://ftp.rediris.es/mirror/openoffice.org/developer/ure_1_0/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Problems compiling OOo_1.1.5 under SUSE 10.0
Arnulf Wiedemann wrote: Hello, I updated my computer to SUSE 10.0 Linux version on an i386 architecture and now I have problems compiling OOo. My existing version OOo_1.1.4 does no longer compile (also calling build only on a subdirectory like bridges). To see if it works, if I start from scratch, I downloded OOo_1.1.5 sources did a configure --prefix=$HOME and started dmake. After about 25000 lines of log output it stopped with the same problem in stlport as with my existing version (OOo_1.1.4). here the start of the log output: cd ./unxlngi4.pro/misc/build/STLport-4.5/src make -f gcc-3.0.mak -j1 touch so_built_so_stlport mkdir -p ../lib/obj/GCC/ReleaseD g++ -D_REENTRANT -DGXX_INCLUDE_PATH=/usr/include/c++/4.0.2 -fexceptions -I../stlport -Wall -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -ftemplate-depth-32 -O2 -fPIC dll_main.cpp -c -o ../lib/obj/GCC/ReleaseD/dll_main.o ../stlport/stl/_alloc.h:416: error: non-template 'rebind' used as template ../stlport/stl/_alloc.h:416: note: use '_Allocator::template rebind' to indicate that it is a template ../stlport/stl/_alloc.h:416: error: declaration does not declare anything ../stlport/stl/_alloc.h:417: error: '_Rebind_type' has not been declared ../stlport/stl/_alloc.h:417: error: expected nested-name-specifier before 'other' ../stlport/stl/_alloc.h:417: error: expected ';' before 'allocator_type' ../stlport/stl/_alloc.h:418: error: 'allocator_type' does not name a type ../stlport/stl/_alloc.h: In function 'typename _STL::_Alloc_traits_Tp, _Allocator::allocator_type _STL::__stl_alloc_create(const _Alloc, const _Tp*)': ../stlport/stl/_alloc.h:460: error: non-template 'rebind' used as template ../stlport/stl/_alloc.h:460: note: use '_Alloc::template rebind' to indicate that it is a template ../stlport/stl/_alloc.h:460: error: declaration does not declare anything ../stlport/stl/_string.h: At global scope: By the way, I had to modify configure to accept gcc version 4, I did that equivalent to gcc Version 3 (as that should be ok AFAIK). As I did not find any hints in the mailing list archives, any help or hint is appreciated. Please ask again on dev@porting.openoffice.org; I guess someone there can help you with compiling OOo on GCC 4. -Stephan Arnulf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[udk-dev] uretest.zip
Hi all, The tests and examples that accompany the URE and that are part of each OOo build (common.pro/bin/uretest.zip) are now also available for easy download at the udk.openoffice.org Documents files section, at http://udk.openoffice.org/files/documents/23/2909/uretest.zip. (And as I just wrote in another mail: I expect to have the OOo 2.0 (RC2) URE (i.e., URE 1.0) available on download.openoffice.org this week.) Enjoy, -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Standalone UNO (URE)
Tim michals wrote: When will a new release be made available? I would more then happy to help test the new releases or builds. I expect to have the OOo 2.0 (RC2) URE (i.e., URE 1.0) available on download.openoffice.org this week. I'm in process of trying to decide between several frameworks UNO (URE) being one of them. But I just need a framework, not OOo. Also, need to have framework in built in debug mode. To have a debug build, you need to build the URE yourself. Unfortunately, you currently need to follow the OOo build instructions, and in module instsetoo_native a URE installation set will fall out of the build process. This, of course, is a time consuming process, in that lots of OOo-specific modules not necessary for URE will also be built. If you only need specific modules with debug information, there should be mechanisms available (a downloadable, pre-built solver) to only re-build those modules; the build instructions on www.openoffice.org should help you there. -Stephan I've been using XPCOM, but would like to try out UNO also -Original Message- From: Ingo Schmidt [mailto:[EMAIL PROTECTED] Sent: Monday, October 10, 2005 4:25 AM To: dev@udk.openoffice.org; Stephan Bergmann Subject: Re: [udk-dev] Standalone UNO (URE) Hi Tim, I do not get Error 2701, but Error 2703. But nevertheless, the Windows URE installation set available at http://ftp.rediris.es/mirror/openoffice.org/developer/ure_1_0/ is a m118, which had an error that breaks the msi database. I do not know, why this broken installation set is available for download. There should be a more recent installation set as soon as possible because this bug is fixed for a long time. If you can use the Orca-Tool to edit the msi-database the problem is very easy to fix. The Orca-Tool is part of Installer SDK and can be downloaded for free from Microsoft. Please unpack the URE installation set by executing the exe-file. You are asked, where to unpack the installation set. In this directory you find a file ure10.msi. This is the msi-database that describes the installation set. Please open this file with the Orca-tool. Look into the table Directory (left column). There you find a directory name FontsFolder which has a defaultdir Fonts:. This is an incorrect name. Please change Fonts: to Fonts (without colon at the end). Then save the msi-Database and start the setup.exe in the local installation set again. Now it should work without problems. Regards Ingo Stephan Bergmann wrote: Tim Michals wrote: I donwnload the windows version and started the installer. URE_1.0_windows_install_en-US.exe 20-Jul-2005 14:42 6.0M A dialog box appeared with the following message: Internal Error 2701. Fontsfoler Is there some way to pull this from CVS and build this project? I would like to have all of the code comiled with debug on so I can use VS 2005 to trace the code. The code for URE is scattered all over the OOo CVS. The actual platform install sets are built in instsetoo_native. Maybe Ingo Schmidt can give a hint on what might be the reason for your specific problem. -Stephan This is on windows XP Service pack 2. The goal is to use UNO for a Windows/Linux project. thanks, tcmichals From: Alexandro Colorado [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: dev@udk.openoffice.org Subject: Re: [udk-dev] Standalone UNO (URE) Date: Fri, 30 Sep 2005 12:30:36 +0200 Tim Michals wrote: Is there a way to download and compile the UNO standalone? If not when? It was my understanding that it would be offered some time during OOo 2.0? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Yes any repository will have it, here is the one from RedIris. http://ftp.rediris.es/mirror/openoffice.org/developer/ure_1_0/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Java filter batch job
Martin Gallwey wrote: Hi there, I wrote some import/export filters and wish to compare the results of a round tripped document with the original document. Thus, I modified the DocumentConverter java sample from the SDK and let it loose on my data. However! On average, the whole JVM crashes on 1 document in 20. This is bad, as I can't be sure if my filters would result in a crash when in use in the wild - although I have never experienced a crash when running in non-batch mode. Is there any reason why performing a batch conversion using the JNI UNO bridge to access Java filters for both import and export could cause problems? Does anyone have any hints or tips on how to track down this error? Any obscure logging options in the JNI UNO bridge I can turn on? The JVM installs a signal handler, so whenever soffice crashes after the JVM has been started in process (and whether or not that crash is in any way releated to using Java), you will see some error output from the JVM. However, this output usually does not help to track down the problem (as usually the crash is in some part of soffice unrelated to Java). The best might be to run soffice from within a debugger to get some more meaningful stacktrace. -Stephan Samples of JVM crash logs are attached. Thanks, Martin [...] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Standalone UNO (URE)
Alexandro Colorado wrote: Tim Michals wrote: Is there a way to download and compile the UNO standalone? If not when? It was my understanding that it would be offered some time during OOo 2.0? Yes any repository will have it, here is the one from RedIris. http://ftp.rediris.es/mirror/openoffice.org/developer/ure_1_0/ ...which will hopefully make it to download.openoffice.org really soon. Also, uretest.zip contains useful tests/examples for programming against the URE, and the contents of that zip are in the CVS at ure/source/uretest. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Thoughts on String Construction / Destruction Performance
Kay Ramme - Sun Germany - Hamburg wrote: Hi guys, Thorsten Behrens wrote: Eike Rathke [EMAIL PROTECTED] writes: A specialized parser could almost certainly be faster than the general SAX parser passing strings back and forth. I wouldn't do it with lex/yacc though, they're a nightmare to maintain, and in case wrong code was generated, which can happen, you're almost lost. I'd prefer boost::spirit instead, but it might be even more work to implement the parser. I've no idea though whether boost::spirit would be suitable to parse an ODF tree. hm. I'd profile a larger test case beforehand - spirit is a recursive parser vs. yacc being table-driven. But OTOH, maybe contemporary optimizers are able to compensate for that. And I'd definitely bump our boost to 1.33, then - spirit (and lots of other stuff) has been improved a lot. At least in theory an unlimited (in the sense of programming language constructs etc.) parser generator, as yacc, should be better than a limited one, as boost::spirit. I know, that in practice the gcc C++ parser, which was AFAIK originally a bison generated parser, has been replaced by a hand written one. Which seems to show that bison does _not_ generate optimal code. yacc/bison can only handle lalr(1) grammars, so if it is difficult/impossible to press your grammar into that form (and for C++ it is at least difficult), you are better off using some other approach than lalr(1). This does not necessarily have anything to do with the performance of the resulting parser, and this definitely has nothing to do with whether a parser generator is implemented as a stand-alone tool or as an embedded DSL. -Stephan Reaching the point where the parser becomes the main bottleneck, we should try out independent implementations, using boost::spirit and bison/yacc. Personally, I am a fan of domain oriented prog. languages and therefor would favor bison. But certainly would be open for everything fastclean :-) Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] pyuno_module.cxx
Joerg Budischewski wrote: Hi, - echo $PYTHONPATH PYTHONPATH: Undefined variable. this is not as it should be. Do you use the standard OOo configure process (or maybe an so environment ? So a setenv PYTHONPATH /so/ws/SRC680/unxlngi6.pro/lib.m130/pyuno:/so/ws/SRC680/unxlngi6.pro/lib.m130:/so/ws/SRC680/unxlngi6.pro/lib.m130/python:/so/ws/SRC680/unxlngi6.pro/lib.m130/python/lib-dynload should do for you. Bye, Joerg Thanks Jörg, For whatever reason, in the Hamburg build env PYTHONPATH is not set (I also had to add the local .../testtools/unxlngi6.pro/lib output directory to PYTHONPATH, or else the test that tries to register samplecomponent would fail). But now, everything works fine, on plain m130 and on CWS warnings01. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] error while instantiate com.sun.star.awt.Toolkit service.
Adriano Colaianni wrote:
I'm registering manually succesfully a new UNO component (implemented in
Java) with regcomp. This is a simple component impementing XMain interface.
After I launch it with UNO Executables:
Unfortunately, many UNO services implemented by OOo only work reliably
within the soffice process. Without having actually checked it, I
assume that com.sun.star.awt.Toolkit is such a problematic service (its
internal use of VCL is a pretty sure sign of that). As a rule of thumb,
those UNO services with UNOIDL specifications in CVS module udkapi
should work independent of OOo and the soffice process, while no such
gurantee is given for CVS module offapi.
A workaround, wich might or might not be useful for you, is to not use
the uno executable to execute your application, but rather make your
application a JAR that uses the simple bootstrap mechanism (which behind
the scenes starts an soffice process and gives your application access
to soffice's component context).
-Stephan
/[EMAIL PROTECTED] program]$ uno -s MyMain -ro services.rdb -ro
types.rdb -ro test.rdb
Arriva 1 !!!
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0xA814C4D5
Function=_ZN11Application8IsInMainEv+0x17
Library=/opt/openoffice.org1.9.125/program/libvcl680li.so
Current Java thread:
at com.sun.star.bridges.jni_uno.JNI_proxy.dispatch_call(Native
Method)
at com.sun.star.bridges.jni_uno.JNI_proxy.invoke(JNI_proxy.java:204)
at $Proxy3.createInstanceWithContext(Unknown Source)
at MyExe.MyAppl.createMainWindow(MyAppl.java:36)
at MyExe.UnoExeMain.run(UnoExeMain.java:26)
...
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_08-b03 mixed mode)
#
# An error report file has been saved as hs_err_pid6736.log.
# Please refer to the file for further information.
#
Aborted/
The exception is raised in:
/package MyExe;
import com.sun.star.uno.Exception;
import com.sun.star.uno.UnoRuntime;
import com.sun.star.lang.XMultiComponentFactory;
import com.sun.star.uno.XComponentContext;
import com.sun.star.awt.XToolkit;
import com.sun.star.awt.XWindow;
import com.sun.star.awt.XWindowPeer;
import com.sun.star.awt.WindowDescriptor;
import com.sun.star.awt.WindowClass;
import com.sun.star.awt.Rectangle;
import com.sun.star.awt.WindowAttribute;
import com.sun.star.frame.XFrame;
public class MyAppl {
/**
* @param args
*/
public MyAppl(XComponentContext c) {
xMCF = c.getServiceManager();
xCCtx = c;
}
public void createMainWindow() {
try {
System.out.println(Arriva 1 !!!);
XFrame xFrame=(com.sun.star.frame.XFrame)
UnoRuntime.queryInterface(
com.sun.star.frame.XFrame.class,
xMCF.createInstanceWithContext(
com.sun.star.frame.Task,xCCtx));
// create Toolkit-Service
--Object oToolkit = xMCF.createInstanceWithContext(
com.sun.star.awt.Toolkit, xCCtx);
System.out.println(Arriva 2 !!!);
XToolkit xToolkit = (XToolkit) UnoRuntime.queryInterface(
XToolkit.class, oToolkit);/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] xpcom_uno module
Darragh Sherwin wrote: Daniel, I have had some success building the xpcom_uno bridge using my own mozilla build (xulrunner). The earlier issue about XPT_NewArena is solved by linking to xul rather than xpcom_core. Seems mozilla have done away with xpcom_core.dll and have move the functions to xul.dll. I have included a patch below for this. Also, in source/xpcom_uno/xpcomvariant.cxx, the nsAString class used is defined as nsAString_external if MOZILLA_INTERNAL_API is undefined, see for information: http://lxr.mozilla.org/mozilla/source/xpcom/string/public/nsStringAPI.h#812 Should MOZILLA_INTERNAL_API be defined? Thanks Darragh, Just to let you know: Daniel is currently on vacation, so it may take a couple of weeks before he can respond. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] how do i avoid interprocess connection?
Adriano Colaianni wrote: Hi all, I want to develop a simple application without the use of interprocess connection (socket, pipe) to create services. Can I create all the service of UNO by a local Service manager (as the example RunComponent.java)? How is it possible? Thanks in advance All the services of UNO is too unspecific to give you a good answer. If you want to use OOo's UNO services (like for editing a text document), then you need the complete OOo application running, and you need to use interprocess communication (nicely shielded by the new simple bootstrap mechanism, available at least in C++ and Java). If you do not need any of OOo's office-related services, but only the base services that are part of the URE (like a service to decompose URLs, or a service to reflectively access other UNO entities), then you should check out the URE. It comes with an accompanying uretest.zip (built in CVS module ure) that contains example UNO applications (using the uno executable, you only need to supply a UNO component that implements com.sun.star.lang.XMain; the uno executable will then provide the component context and service manager and instantiate your component). This might be too broad an overview for your specific needs. Don't hesitate to ask for details, depending on which way you want to go. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] pyuno_module.cxx
Joerg Budischewski wrote:
Hi Stephan,
you can remove the runtime instances, they just cash some hashmap
lookups and have no side effects. The PyThreadAttach/Detach classes on
the other hand have side effects and cannot be removed.
Would be nice if you can execute the pyuno tests in
testtools/source/bridgetest/pyuno (at best before and ) after your
modifications. You currently need to set UNO_TYPES and UNO_SERVICES
environment variable to the values passed formerly by using the -env:
command line switches, just have a look in the makefile.
I'm too dumb to get that working, independent of the CWS changes. What
exactly do I need to do on a plain SRC680m130 to execute that test (on
Linux)?
-Stephan
Umn, I know, pyuno currently raises a lot of warnings, hope, you get
through though.
Good luck and bye,
Joerg
Stephan Bergmann wrote:
Friends and maintainers of pyuno, :)
Making our code base warning-clean (see thread on dev@openoffice.org),
I stumbled over a detail in pyuno/source/module/pyuno_module.cxx rev.
1.9.14.1 I am not sure how to resolve: The two functions PyEnum2Enum
and PyType2Type used to take a Runtime argument that they did not use,
so I removed it. However, in lines 458 and 483 of pyuno_module.cxx,
these functions got called with a freshly created Runtime instance:
{
Runtime runtime;
PyType2Type( obj, runtime );
}
and I am not sure whether the Runtime constructor should still be
called for side effects:
{
Runtime runtime;
PyType2Type( obj );
}
or whether that is not needed:
{
PyType2Type( obj );
}
-Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] how do i avoid interprocess connection?
Adriano Colaianni wrote: Does Applications like Draw, Impress, make interprocess connection to instantiate UNO's Services? How do they work? I'm going to develop a simple application that works at the same level of Draw or Impress (no OOo client application ). After an explanation of Developer's Guide I have the next scenario: Client| S U |service1| ? |Impress Appl. | O R |. | ? |Draw | C P |.UNO| ? |Writer | K |. | ? |. | E |. | ? |. | T |serviceN| ? |. Impress, Writer, etc. are part of the soffice process, and as such access any OOo UNO services in-process (in fact, each of Impress, Writer, etc. also *implements* its share of those OOo UNO services). If the entity you develop is intended to be an integral part of OOo, like Draw, Impress, Writer, etc., then it looks like it should be a (UNO) component that is instantiated within the soffice process (and for details on how to integrate it into OOo's menus etc. dev@api.openoffice.org would probably be the right mailing list). -Stephan Stephan Bergmann wrote: Adriano Colaianni wrote: Hi all, I want to develop a simple application without the use of interprocess connection (socket, pipe) to create services. Can I create all the service of UNO by a local Service manager (as the example RunComponent.java)? How is it possible? Thanks in advance All the services of UNO is too unspecific to give you a good answer. If you want to use OOo's UNO services (like for editing a text document), then you need the complete OOo application running, and you need to use interprocess communication (nicely shielded by the new simple bootstrap mechanism, available at least in C++ and Java). If you do not need any of OOo's office-related services, but only the base services that are part of the URE (like a service to decompose URLs, or a service to reflectively access other UNO entities), then you should check out the URE. It comes with an accompanying uretest.zip (built in CVS module ure) that contains example UNO applications (using the uno executable, you only need to supply a UNO component that implements com.sun.star.lang.XMain; the uno executable will then provide the component context and service manager and instantiate your component). This might be too broad an overview for your specific needs. Don't hesitate to ask for details, depending on which way you want to go. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] pyuno_module.cxx
Joerg Budischewski wrote:
Hi Stephan,
you can remove the runtime instances, they just cash some hashmap
lookups and have no side effects. The PyThreadAttach/Detach classes on
the other hand have side effects and cannot be removed.
Would be nice if you can execute the pyuno tests in
testtools/source/bridgetest/pyuno (at best before and ) after your
modifications. You currently need to set UNO_TYPES and UNO_SERVICES
environment variable to the values passed formerly by using the -env:
command line switches, just have a look in the makefile.
I will do that.
Umn, I know, pyuno currently raises a lot of warnings, hope, you get
through though.
Not thaaat many, actually (at least on Solaris and Linux)...
Thanks,
-Stephan
Good luck and bye,
Joerg
Stephan Bergmann wrote:
Friends and maintainers of pyuno, :)
Making our code base warning-clean (see thread on dev@openoffice.org),
I stumbled over a detail in pyuno/source/module/pyuno_module.cxx rev.
1.9.14.1 I am not sure how to resolve: The two functions PyEnum2Enum
and PyType2Type used to take a Runtime argument that they did not use,
so I removed it. However, in lines 458 and 483 of pyuno_module.cxx,
these functions got called with a freshly created Runtime instance:
{
Runtime runtime;
PyType2Type( obj, runtime );
}
and I am not sure whether the Runtime constructor should still be
called for side effects:
{
Runtime runtime;
PyType2Type( obj );
}
or whether that is not needed:
{
PyType2Type( obj );
}
-Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[udk-dev] pyuno_module.cxx
Friends and maintainers of pyuno, :)
Making our code base warning-clean (see thread on dev@openoffice.org), I
stumbled over a detail in pyuno/source/module/pyuno_module.cxx rev.
1.9.14.1 I am not sure how to resolve: The two functions PyEnum2Enum
and PyType2Type used to take a Runtime argument that they did not use,
so I removed it. However, in lines 458 and 483 of pyuno_module.cxx,
these functions got called with a freshly created Runtime instance:
{
Runtime runtime;
PyType2Type( obj, runtime );
}
and I am not sure whether the Runtime constructor should still be called
for side effects:
{
Runtime runtime;
PyType2Type( obj );
}
or whether that is not needed:
{
PyType2Type( obj );
}
-Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] How to recognize a Service with XInvocation
Arnulf Wiedemann wrote: Hi Stephan, Am Mittwoch, 7. September 2005 14:51 schrieb Stephan Bergmann: Arnulf Wiedemann wrote: Hi, using XInvocation2 method getMemberNames I can get all the methods and properties of an object. Using XInvocation hasMethod and hasProperty I can distinguish between methods and properties. I don't know XInvocation in detail, but from looking at the documentation, XInvocation2.getInfo() seems to be your friend here. sorry, that does not help, there is a lot of information available in InvocationInfo, but nothing which tells me, if that is a service. XInvocation is about the interface methods (and maybe interface attributes---I do not know) and XPropertySet-related properties supported by an object; services have nothing to do with that. In the list of properties there are sometimes service names. Can you give an example of that (what kind of object did you inspect)? This sounds like an error to me. the object is a com.sun.star.frame.Desktop, created with a createInstanceWithContext. The funny property is: DispatchRecorderSupplier It appears that the given object supports (via its XPropertySet interface) a property named DispatchRecordSupplier. That there is also a service named com.sun.star.frame.DispatchRecordSupplier is a coincidence. It is in the list returned from getMemberNames and hasProperty returns true for that member name, whereas hasMethod returns false (which is correct). If I use the Desktop object and call getPropertyValue with parameter DispatchRecorderSupplier I get the strange object index back. com.sun.star.beans.XPropertySet.getPropertyValue returns a value of type ANY. I assume that in your case it returns a value of type ANY that containts a value of an interface type (probably because the given property named DispatchRecordSupplier is of an interface type---I do not know). For a value of an interface type, URP uses the combination of an empty OID string and a cache index of 0x to represent the null reference. In other words, getPropertyValue(DispatchRecordSupplier) happens to return a null reference in your case. (By the way, XInvocation appears to be somewhat flawed, as it throws together interface methods and XPropertySet-related properties, which can lead to name clashes.) -Stephan Arnulf -Stephan How can I find out, that a property is a service name? I only found out the using getPropertyValue on a service I get an empty object id and an object cache index 0x directly from the urp protocol. Are that the criteria for a service? Arnulf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
