[Fwd: Re: [udk-dev] Problems on Clear Separation of C and C++ Uno]
Resending, as it seems that it has not gone through ... ---BeginMessage--- Hi Cynthia, Canghua Qu wrote: Hi, all, It is very nice to join this mailist. :-) A warm welcome and I hope you enjoy it :-) I am Canghua Qu. My English name is Cynthia. Nice to meet you. I am a developer of Open Source Department CH2000 China. Xiuzhi Cheng is our department Leader. Li Yuan is my colleague. I have been doing something with OOo codes for 10 monthes. I like doing things in OOo and would like to do more contribution. Sounds great. I am interested in the task: Clear Separation of C and C++ Uno. And several monthes ago, my partner Li Yuan accepted the task. As he is busy on other tasks, I would like to do it. But I am new in this field, so I need your help and guidance. :-) I am going to support you, as my time allows. As I got the information here: http://wiki.services.openoffice.org/wiki/Uno/To-Dos and here: http://udk.openoffice.org/servlets/ReadMsg?listName=devmsgNo=3708 I see ... What I have known are as follows: 1. We are doing this task on Binary UNO as the chart of the link: http://wiki.services.openoffice.org/wiki/Uno. And the construct of the Binary UNO is described on the link: http://wiki.services.openoffice.org/wiki/Uno/Binary Yes. 2.The C Uno runtime is implemented in C++ -- So we need to make C UNO runtime is writen with C language in this task. Not necessarily, depends on what we want. I can imagine having a C Uno Runtime, being implemented (partly) in C++, only importing and exporting C ABIs. Though we may want to discuss this with other Uno interested parties on this alias. 3.The C++ Uno runtime offers various functions for bootstrapping Uno, which are not yet available for Binary Uno. -- So we need to make the new C UNO runtiime offers various functions for bootstrapping Uno, too. Yes. 4. The task's purpose is making udk/cppu for C UNO, and udk/cppuhelper is for C++ . And Binary UNO will be C UNO and will be writen in C. Mostly yes. Though the C Runtime may be implemented in C++, as long as no C++ dependencies / provisions are made. Are they right? These are the tasks. And my problem is: What exactly meaning of C++ stuff in the task's first step Move C++ stuff from udk/cppu to udk/cppuhelper. Shall I take it just as moving the code sections which is compiled with C++ compiler ? And leave along the code sections which is compiled with C compiler? Basically yes. Unfortunately it is not as easy as it may look like, because of build dependencies (e.g. moving all C++ out of cppu to cppuhelper is not possible, because cppuhelper is build after cppu and only delivers its headers after cppu, while cppu is implemented in C++ and relies on these headers). Looking forward to your eariliest reply at convenient time! And thanks very much! :-) I thank you for your interest! Best Regards, Cynthia 2007-10-29 Kay ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] (tid=3) Unexpected connection closure
Hi Lucasz, if I understand your other mail correctly, the office dies for some reason. You may want to attach a debugger or something to see what happens. How are you actually starting the office process? If it is under your control, you may want to issue a wait (or similar) system call. The moment wait returns you know the process died. Just try the non-headless approach to see if it does crash as well, obviously headless and non-headless should behave the same wrt to the API :-) Regards Kay Lukasz Szybalski wrote: On Mon, Nov 9, 2009 at 9:01 AM, Etienne Gaudrain et.gaudr...@free.fr wrote: Hi Lucas, Here are two things you may try : - use a pipe connection instead of a socket connection, and see if you still lost connection ok. lets try the pipe.. What is the difference between socket and a pipe as far as oo? Can I start multiple instances of oo with different pipe names and then use these pipe names for multiple programs that start around the same time? doing changed the startup from /usr/bin/openoffice -accept=socket,host=localhost,port=8100;urp; -norestore -nologo -headless -nofirstwizard to /usr/bin/openoffice -accept=pipe,name=localhost_app;urp; -norestore -nofirstwizard -nologo -headless Now in the code I did: import uno from com.sun.star.beans import PropertyValue from com.sun.star.connection import NoConnectException localContext = uno.getComponentContext() resolver = localContext.ServiceManager.createInstanceWithContext(com.sun.star.bridge.UnoUrlResolver, localContext) context = None context = resolver.resolve(uno:pipe,name=localhost_app;urp;StarOffice.ComponentContext) desktop = context.ServiceManager.createInstanceWithContext(com.sun.star.frame.Desktop, context) but still get the connection lostno change...(I wonder if I can use the NoConnectException somehow??) troubleshooting I've tried recreating the cursor every time the new section/action needs to be done. This has improved the process but still 1/5 fail in headless. What I noticed is that if headless process crashes, I can start the non-headless process and that will finish just fine, so it seems as headless startup will lose connection more often then the non headless one. Since I start and stop oo from the script I really need to get the headless package to work properly. - check that the OOo process is still running. Actually, you may want to use the subprocess module instead of the os one (you just be loosing compatibility with Python 2.3). You would be able to grab errors from the stderror channel of your process. I don't know if it throw any message there, but in case it does, you'd be able to read it. There are no error messages when oo crashes. If I start the oo on the socket then process is still running but its no longer listening on the socket. This will show a lot of soffice processes after few days of running the process in cron ps -ea | grep soffice But this command will show that none of them are listening anymore...netstat -atpen | grep soffice As far as pipe, i see its closing right now but I would need few days to see if the process closes when using cron? Ideas? Thanks, Lucas Regards, -Etienne Lukasz Szybalski wrote: On Mon, Nov 9, 2009 at 2:29 AM, Kay Ramme kay.ra...@sun.com wrote: Hi Lukasz, this is a Python question, right? Typically connections die, because one of the hosts get disconnected or one of the applications do terminate. Do you have a hint, which case is yours? It seems as there is a exception in openoffice services. Service terminates without sending back an error message, and its no longer listening on the port. When that happens I get a message on the next oo call that the connection was lost. So at this point I'm looking for a way for oo to tell me that it failed, or look at some log that oo? creates to see why it failed? Is there a log for the headless services oo is running? Thanks, Lucas - To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org For additional commands, e-mail: dev-h...@udk.openoffice.org -- Sun Microsystems GmbH Kay Ramme Sachsenfeld 4 Senior Technical Architect 20097 Hamburg Phone: (+49 40) 23646 982 Germany Fax: (+49 40) 23646 550 http://www.sun.com/staroffice mailto:kay.ra...@sun.com http://www.sun.com/openoffice http://udk.openoffice.org Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Häring - 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
Ahhh, I missed this mail ;-) As Stephan said, it is probably better to ask on the go-oo lists or to switch to vanilla (http://download.openoffice.org). Regards Kay Stephan Bergmann wrote: 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 - To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org For additional commands, e-mail: dev-h...@udk.openoffice.org
Re: [udk-dev] Requirements for UNO-CLI in OOo 2.0 and .NET
Hi, Joachim Lingner wrote: Hi, Martin Kretzschmar wrote: Hi, [snip] If I read the code correctly, a pure C# version of UNO-CLI is not possible, because the bridge has to have C linkage. The binary UNO interface is defined in C. That means, that a CLI runtime must be accessable through a C interface. For example, the Java bridge uses the Java Native Interface. That code would not quite correct, an implementation of the UnoRemoteProtocol (URP) would do it as well. Actually decoupling any two bridges on an ABI level. [snap] Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] URP and the Current Context
Stephan Bergmann wrote: Joerg Budischewski wrote: Hi, Stephan Bergmann wrote: [...] BTW, do you know whether PyUNO and the bridge between PyUNO and binary UNO already support the current context? It seems, that I have overlooked this. How about other scripting languages (ole, basic) ? I can add very simple native runtime functions to pyuno to allow the access (wrappers arrount get/setCurrentContext() functions). I think this is the best solution (we will also use it for CLI UNO). When a given UNO environment is designed so that the cppu dynamic library is available in process, anyway, it is the best choice to re-use the binary UNO current context mechanism from cppu in that UNO environment, too. This seems to be the case for PyUNO and CLI UNO, for example. (It is not the case for Java UNO, which can be run in a Java-only process, so Java UNO has its own current context---which it has to synchronize with other potential current contexts within the same process, but doesn't at the moment.) Could it be another option to add a CurrentContextHolder property to the component context ? The property would be an uno object with just one property (currentContext), which simply delegates to the C++ get/setCurrentContext() runtime functions. Such a functionality could be used by all scripting languages. I don't like the idea of using UNO to implement functionality of the UNO runtime substrate. This has shown to be bad more often than not (the three UNO methods of XInterface; aggregation; etc.). I second this opinion. -Stephan Kay But errors in script code (not layering the context correctly) can easily generate very strange and difficult to debug side effects, so I am not 100% sure, that this a gread idea. Bye, Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] URE and C++ vs. C on Linux
Hi Dan, Dan Kegel wrote: Christian Junker [EMAIL PROTECTED] wrote: [Apologies if I'm treading old ground, or anyone's toes, or spouding nonsense. I have hardly looked at the UDK before. I do have some experience supporting multiple versions of g++, though.] Is that practical? If it is, it might be a good idea. The core is already 'C' based. Please see my other posting. The C++ ABI on Linux is a moving target; it has changed with every minor release of gcc (except 4.0, which uses the same ABI as 3.4). The C++ ABI will be changing again with gcc-4.1. That means that there is essentially no hope of having a single binary library written in C++ ship and work with all Linux distributions. (I'm exaggerating here, but only a little.) There are extremely good reasons for the ABI changes (and I'm pushing for one of the ABI changes in gcc-4.1, so I'm glad it's happening), so I'm not criticizing the gcc developers, simply stating the facts. What is disturbing here is, that it even (as you said) breaks in minors, AFAIK even without notice, and sometimes it seems even without intention. What is also disturbing, is the handling of libgcc_s.so, which you on the one hand need to ship with program, but which partly breaks binary compatibility on the other hand. Anyway, things are improving and I am pretty sure they will be sorted out in the (near?) future. The C ABI on Linux, on the other hand, remains relatively rock-solid. Any low-level library that wants to have a hope of being universally usable should strongly consider being based solely on C and not on C++. Actually, a C-library differs to C++-library only in terms of ABI and does not need to differ in terms of implementation language. In other words, it should be perfectly valid, to implement a library providing a C interface in C++. The implementation language should really be an implementation detail. Now, the UDK has to have C++ bindings for convenience of C++ developers. It might be worth considering making these bindings available for multiple versions of the Linux C++ ABI simultaneously on the same machine (via different shared library major version numbers, perhaps). This would be possible if (and perhaps only if) the guts were in C, so the C++ binding really was just a shallow adaptor. We are are on it. Please see my other posting. Finally, on an optimistic note, I do think the rate of change in the C++ ABI is slowing down, and there's a chance that the gcc-4.1 C++ ABI will last a couple years, and might even (as part of LSB 4.0) be around for a decade. My opinion here is, that sometimes it is more important to provide a stable platform than to slow down adoption, e.g. by changing interfaces/ABIs/APIs etc. No flame intended :-). I'd also like to point to the LSB (Linux Standard Base) as a source of hope; LSB 3.0 will provide an island of stability for C++ apps which might let you ignore some of the above issues at the cost of having to help cheerlead LSB adoption. Yep, were are quite aware of that. At least we have a clue of LSB 2.x :-). - Dan Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] details about urp release call
Stephan Bergmann wrote: The overall validity of turning off MUSTREPLY and SYNCHRONOUS for a normal (not one-way) UNO interface method invocation is at least questionable. One basic property of UNO is that a sequence of method invocations (of not--one-way methods) is executed sequentially, in a single UNO thread. This is guaranteed anyway, respectively might be controlled by the caller. Again, forcing synchronous calls to asynchronous behavior would have been offered via CuCas and is not yet utilized. The reason for acquiring objects passed in synchronous calls is the acquire method being oneway, avoiding potential races between a client acquiring (sending an acquire request) an object passed to a synchronous call and returning from this synchronous call. There is neither an acquire method in UNO (com.sun.star.uno.XInterface's acquire is an implementation detail of the C++--UNO language binding, that unfortunately got exposed), nor is there an acquire message in URP. Correct. For the above reasons, this is not needed (has been avoided). Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Question concerning urp protocoll
Hi Arnulf, AFAIR a Sequence is marshaled as compressed number n # the size of the sequence value * n # the sequences elements, where the type of value depends on the sequences type an Any is marshaled as Type # the type of the Any value # the value of the Any, value is of type Type So, an Any with a Sequence looks like this Type = SequenceSType compressed number n value * n URP is implemented in C++ _and_ Java. So, in case the C++ implementation is understandable on the first glance, you might want to look at the Java implementation (jurt/com/sun/star/lib/protocols/urp). The source of truth is certainly the spec., to be found here http://udk.openoffice.org/common/man/spec/urp.html In URP, everything is predictive, that an unmarshaler does need to temporarily store anything. Hope that helps Kay Arnulf Wiedemann wrote: Hi, I am trying to use the XInvocation invoke function and generating directly the urp protocol input to be read from a ooo server started listening on the urp protocoll socket. This is working correctly for some calls, but there is a problem using the XComponentLoader loadComponentFromURL method. invoke expects for the aParams Parameter a sequenceany That works ok for the first three arguments of loadComponentFromURL: URL string - TypeClass STRING and a compressed String TargetFrameName - TypeClass STRING and a compressed String SearchFlags long- TypeClass LONG and a long value Arguments - ??? (I am trying: TypeClass SEQUENCE and the type_cache_index for ::com::sun::star::beans::PropertyValue followed by the marshalled STRUCT members, with no success) How can I marshal a sequence ::com::sun::star::beans::PropertyValue ? Reading the code in source/remote/urp/urp_unmarshal.cxx: Unpacking a sequence of ANY in the OReaderThread on the server calls for every member of that sequence the method unpack for ANY. Within case typelib_TypeClass_ANY: method unpackType is called and for types 14 (SEQUENCE == 20) after unpacking the nTypeClass, a typecache index is expected (file urp_unmarshal.cxx). I made that type for the typecache index ::com::sun::star::beans::PropertyValue (marshaling the appropriate nCacheIndex), and after the call to method unpackType on the server side in that case directly a ::com::sun::star::beans::PropertyValue STRUCT is expected method unpack (in file urp_unmarshal.cxx), because nCacheIndex forces the type to be ::com::sun::star::beans::PropertyValue (== STRUCT). I think that is not correct, because in the case of a SEQUENCE (within an ANY) there should be first a call to determine the size of the sequence and after have the sequence_size the elements of the sequence should be unmarshalled (in my case the ::com::sun::star::beans::PropertyValue STRUCT elements). I have tried a lot of different ways for marhsaling the Arguments parameter with no success (either with a no conversion possible exception or passing the code with the comment severe error during extracting, dispose comment). Or is there another way for marshaling the Arguments parameter on the client side? Arnulf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Thoughts on String Construction / Destruction Performance
Hi Niklas, Niklas Nebel wrote: Taking an attribute name as an example, with the SAX interface inbetween, the via callbacks part looks (roughly) like this: The name is copied into a vector for the XAttributeList implementation, copied again for two getNameByIndex calls (one to look for namespace attributes, one in the implementation of the cell element context), then a hash_map is used to separate it into a namespace ID and local name. That is correct. Some of the copy operations may easily be omitted, but with nearly no measurable impact. Considering this, the calculation might me a bit simplistic. The calculation just gives, what the optimum (minimum) looks like. If the implementation does more string instantiations than calculated, than it is obviously not optimal (in this aspect) and the impact of string con- / destruction is increased. Niklas Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Thoughts on String Construction / Destruction Performance
Hi Niklas, Niklas Nebel wrote: Kay Ramme - Sun Germany - Hamburg wrote: The calculation just gives, what the optimum (minimum) looks like. If the implementation does more string instantiations than calculated, than it is obviously not optimal (in this aspect) and the impact of string con- / destruction is increased. You're right. But real numbers, also for the memory overhead in a complete running office, would sure be interesting. this numbers obviously need to be measured. If they differ from what we calculated, then we know that the implementations are not optimal (which we probably know already anyway ;-), but I think the point is, that we can judge the implementation. E.g. if the predicated value for string instantiations is X and we measure 100 x X, we know that we are relatively far away from the optimum and need to do some optimizations, but if we measure 1.1 x X, than we know we are already near the optimum and that it will probably be hard to improve performance further. Hope you understand what I mean ;-). Another thing: test_character_copy looks somewhat strange. 100 iterations of memcpy for 1024 bytes each, and the total time divided by 1024? Hey, that is a bug! Thanks for pointing this out. Oh well, that happens when one is too lazy to follow the little obscurities. That probably means, that a sal_Unicode copy is much less (1/100) expansive than 34 insts. I will update the calculations accordingly. Niklas Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] applicat.rdb ?
Adriano, Adriano Colaianni wrote: sound like you may obtain a new Developer's Guide ;-). The current Developer's Guide talks still about /applicat.rdb/. Please file an issue to Juergen Schmidt for this. The services.rdb is for UNO service registration. The types.rdb is the UNO type repository. So, if you want to register services by hand (e.g. with regcomp), register them into the services.rdb. If you want to add types, merge them into types.rdb. Kay Stephan Wunderlich - Sun Germany - ham02 - Hamburg wrote: Hi Adriano, in the Developer's Guide, the main component's registry file is /applicat.rdb/. My OOo installation have this registry: /services.rdb/, /setup_services.rdb/, /types.rdb/. How is the correct match ? sound like you have an old DevelopersGuide ;-) What you registered formerly in the applicat.rdb you could now register in the types.rdb ... BUT there is a more convenient way to register your component in the office by using pkgck (OOo1.1.x) or unopkg (OOo1.9.x). The page http://api.openoffice.org/docs/DevelopersGuide/Components/Components.htm might contain further interesting and more detailed information for you. Hope that helps Regards Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Segmentation fault
Adriano, Adriano Colaianni wrote: I've tried to compile a register for a new component implementation in UnoExeMain.jar. The result is segmentation Fault. What is the reason? [EMAIL PROTECTED] eclipsews]$ regcomp -register -br /sp/home/acolaianni/OpenOffice.org1.1.5/program/types.rdb -br /sp/home/acolaianni/OpenOffice.org1.1.5/program/services.rdb -r test.rdb -c ./UnoExeMain.jar -l com.sun.star.loader.Java2 Segmentation fault [EMAIL PROTECTED] eclipsews]$ it is much easier to see what's going wrong, if you provide a stack trace, e.g. by using gdb. Also, often strace regcomp .. | grep open helps, to see if a file missing. Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] xpcom_uno module
Hi Darragh, Daniel is on vacation for quite a while. So, answering this is going to be delayed. Kay 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] xpcom_uno module
I was first :-) Stephan Bergmann wrote: 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] - 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.
Stephan Bergmann wrote: 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, It used to be usable independently, some years ago. First try would be, to ensure that you have everything in the path needed. Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Thoughts on String Construction / Destruction Performance
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. 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] Re: [api-dev] Python equivalent to com.sun.star.comp.helper.Bootstrap.bootstrap()?
Hi Joerg, Joerg Budischewski wrote: Hi, sorry to warm this topic up again ... While disagreeing to have such a bootstrap() function in cppuhelper (this function simply can't work in SDK without office, how should cppuhelper know, that it is running in an office environment), as it agreed, the current implementation is more or less suboptimal. The bootstrap() stuff is currently _not_ useable in an URE. Same holds true for unopkg. The plan (for OOo 3.0) is, to change bootstrap() in a way, that it provides the currently URE registered components / services / objects, while simultaneously changing the office to depend on the URE and to register itself during deployment at the URE. So, please just regard this as the first steps. exists, it should be made usable in pyuno. I have not taken a look at what has been implemented, obviously the pyuno bootstrap() stuff needs to be seamless pyuno. Meaning, that one should be able to use it in an 100% pure python environment. Certainly no cppuhelper or any such naming should be used. Christian Junker provided a first patch for bootstrapping with this function in pyuno (Thank you !, see http://www.openoffice.org/issues/show_bug.cgi?id=54532 ), but this is not an ideal solution. Will take a look later ... When I use the office context for pyuno bridge, pyuno will get a performance penalty, because I use e.g. components like TypeConverter during bridging calls, which will end in multiple overhead remote calls per pyuno call and pyuno doesn't work anymore when the office is down. So I need the local context used in bootstrap, but this is unreachable lost in the cppuhelper bootstrap() function. So the only chance I have currently is to bootstrap a second context, this is not nice at all and has other side effects. Any thoughts ? See above, pyuno should probably be treated like Java. All the bootstrap() stuff is about getting _the_ ComponentContext. If this is the context of the underlying URE, or just the one in a 100% pure python environment may vary, dependent on the usage / deployment scenario. (Unfortunately we named the bootstrap() stuff wrong, as it is _not_ about bootstrapping, but _getting_ a ComponentContext.) Bye, Joerg Kay Kay Ramme - Sun Germany - Hamburg wrote: Hi Joerg, Joerg Budischewski wrote: I am actually also not sure, whether this belongs in a core api. This function is a nice helper for starting to program with the office but it hides too much away imho ( if the office process cannot be reached, the function loops endlessly, it always an office process even when an office is running, etc.) to be used in a professional application. that bootstrap currently starts an office process is an implementation detail only. Actually we chose the wrong name for it, when we implemented it. The right name would have been something like ReferenceXComponentContext getComponentContext(); The semantics are, that this function returns the systems (which could be a process, a user, a host, a LAN, a WAN, ...) component context. The height of the abstraction allows us, to basically implement / optimize everything behind the scenes, while providing a compelling and simple to use interface for developers. In my understanding, especially professional developers want to mostly deal with the customers problem, and less with nasty API details. Bye, Joerg Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Merits of spirit yacc
Thorsten Behrens wrote: According to other people, spirit _is_ a DSEL (domain-specific embedded language) - when given the choice, I prefer embedded DSLs over external ones. :-) Ohhh, from what I understood from others, I thought you 'd have to construct a parser by C++ statements (using a kind of library). Being it a DSL is even better, and renders it IMHO a friend of yaccbison. So, fine for me anyway :-) Cheers, Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Thoughts on String Construction / Destruction Performance
Stephan Bergmann wrote: 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 You are right. 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. If I understand correctly (not yet taken a look at the code Thorsten pointed to, but promise to do so :-), an embedded parser gets generated at runtime, while yacc/bison generate the parser at compile time. -Stephan Kay 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Merits of spirit yacc
Thorsten Behrens wrote: Kay Ramme - Sun Germany - Hamburg [EMAIL PROTECTED] writes: Thorsten Behrens wrote: According to other people, spirit _is_ a DSEL (domain-specific embedded language) - when given the choice, I prefer embedded DSLs over external ones. :-) Ohhh, from what I understood from others, I thought you 'd have to construct a parser by C++ statements (using a kind of library). Yes, your initial thought is correct - it's an _embedded_ DSL. Look at slideshow/source/engine/smilfunctionparser.cxx around line 454 to get an impression how the grammar looks like (BTW: the messy semantic actions there could be expressed _much_ more elegantly with an 1.33er spirit). Thanks, will take a look. Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[udk-dev] State of OOo Multi Threading
Hi guys, some of you might be interested in OOo multi threading. We prepared a first document, mainly listing what we think the issues are. You can find it here: http://udk.openoffice.org/files/documents/23/3029/OOo_multi_threading__status_0_3.odt Agreeing on these issues is just the first step. So, please give feedback of things missing / being wrong etc. Thanks Kai and Kay P.S.: Follow up on dev@udk.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[udk-dev] State of OOo Multi Threading
Hi guys, some of you might be interested in OOo multi threading. We prepared a first document, mainly listing what we think the issues are. You can find it here: http://udk.openoffice.org/files/documents/23/3029/OOo_multi_threading__status_0_3.odt Agreeing on these issues is just the first step. So, please give feedback of things missing / being wrong etc. Thanks Kai and Kay P.S.: Follow up on dev@udk.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Java filter batch job
Hi Martin, just two points: - If the hanging finalizer really is the problem, than one dedicated thread for releasing/finalizing mapped UNO objects should do the trick, no thread pool needed. The Java finalizer just needs to pass these objects to the releaser thread. - How does you ensure that your thread pool threads finalize the objects? AFAIK there is no way to explicitly dispose mapped UNO objects. Kay Martin Gallwey 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. Because the JVM finalizer garbage collects many many objects at a time (in the scenario where I ran into this bug, the high water mark was 1), it is not possible to create a thread per release. What I did instead was turn on '-Xincgc' for incremental garbage collection, and implement a thread pool of ten threads to share out the releasing of the objects. I will create a child workspace for this issue. In the mean time, I created an issue (i#57753#) with the patches attached to it. With the attached patches, my java filter batch job ran perfectly for 8000 documents, whereas without the patches it used to crash after 20 or so. I'll create a reduced test case to demonstrate the crash. It seems the 'access violation exception' was a result of the java.lang.OutOfMemoryError as with the patches applied, I get neither error. Have a good weekend, everyone! Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Java filter batch job
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? 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. Anyway: The problem basically is caused by current Java implementations only supporting asynchronous finalization! Solutions are: -A- Implement synchronous finalization for Java = possible for some kind of objects, unlikely to happen, reliability would rely on specific behavior. = not viable -B- Don't use the finalizer for releasing mapped objects. That would mean, that one had to program release/acquire or dispose explicitly, which would be quite error prone. = not viable -C- Don't acquire any mutexes in (c++) d'tors on the office side. Theoretically possible. In practice that would mean that for every kind of object which is not only holding memory but other external resources (device contexts, file handles, sockets, etc.), one would need to call dispose. Hard to program and again error prone (at the end one would have to offer/use dispose for all objects, because not wanting to rely/show implementation details (e.g. holding a file handle may very well be an implementation detail)) . = IMHO not viable again (I know, others have other opinions ;-). -D- Defer the problem, e.g. delegate the release calls out of the finalizer thread into another thread. But, because of this other thread waiting for the mutex, this eventually leads to the same problems we see currently. = IMHO also not viable. So, it seems no final solution at the horizon? I think we should approach this differently. IMO, the main questions is, what is the reason that some many objects become created while doing a long living call into the office? Martin, could you give some hints? Kay It is IMHO not arguable, the problem is clearly office related! Otherwise -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] State of OOo Multi Threading
Hi guys, I updated the document again, new version is 1.0 (final). http://udk.openoffice.org/files/documents/23/3052/OOo_multi_threading__status_1_0.odt Changes: - added numbers - added DD crasher - some wording - improved formatting I am going to create a project page regarding the OOo threading clean-up effort. Kay Kay Ramme - Sun Germany - Hamburg wrote: Hi, I updated the document to v0.4. http://udk.openoffice.org/files/documents/23/3029/OOo_multi_threading__status_0_4.odt Changes: - Added multi threaded office crasher example. - Changed some wording. - Added list of open tasks to finalize the document. Kay Kay Ramme - Sun Germany - Hamburg wrote: Hi guys, some of you might be interested in OOo multi threading. We prepared a first document, mainly listing what we think the issues are. You can find it here: http://udk.openoffice.org/files/documents/23/3029/OOo_multi_threading__status_0_3.odt Agreeing on these issues is just the first step. So, please give feedback of things missing / being wrong etc. Thanks Kai and Kay P.S.: Follow up on dev@udk.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] State of OOo Multi Threading
Hi again, I created a web page for the OOo Multi Threading Clean up Effort at http://udk.openoffice.org/projects/threading/index.html This page is certainly also reachable from the UDK http://udk.openoffice.org/ project. Regards Kay Kay Ramme - Sun Germany - Hamburg wrote: Hi guys, I updated the document again, new version is 1.0 (final). http://udk.openoffice.org/files/documents/23/3052/OOo_multi_threading__status_1_0.odt Changes: - added numbers - added DD crasher - some wording - improved formatting I am going to create a project page regarding the OOo threading clean-up effort. Kay Kay Ramme - Sun Germany - Hamburg wrote: Hi, I updated the document to v0.4. http://udk.openoffice.org/files/documents/23/3029/OOo_multi_threading__status_0_4.odt Changes: - Added multi threaded office crasher example. - Changed some wording. - Added list of open tasks to finalize the document. Kay Kay Ramme - Sun Germany - Hamburg wrote: Hi guys, some of you might be interested in OOo multi threading. We prepared a first document, mainly listing what we think the issues are. You can find it here: http://udk.openoffice.org/files/documents/23/3029/OOo_multi_threading__status_0_3.odt Agreeing on these issues is just the first step. So, please give feedback of things missing / being wrong etc. Thanks Kai and Kay P.S.: Follow up on dev@udk.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] ANNOUNCE: tcluno release 0.2
Arnulf, that is great news! I probably have the time next week to give it a try :-) Regards Kay Arnulf Wiedemann wrote: The tcluno team is pleased to announce release 0.2 of tcluno. Tcluno is a set of Tcl packages, which provide acccess to OpenOffice.org using the urp socket interface. Since release 0.1 the C/C++ part has been eliminated and the packages are Tcl only now. One part of the packages (unospection) allows interactive introspection and driving of a running OpenOffice.org process (server). If somebody is interested please have a look here: https://sourceforge.net/projects/tcluno Cheers, Arnulf Wiedemann Wolfgang Großer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] A request for com.sun.star.lang.XEventListener
Rony, Rony G. Flatscher wrote: Hi there, 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? What would the usage scenario look like? Do you have an example at hand? So the request would be to declare XEventListener to implement java.util.EventListener. Regards, ---rony Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] User-Question: Are TableColumnSeparators working properly?
Thomas, I suggest to resend your mail to dev@api.openoffice.org, which seems to be more appropriate regarding your questions. Kay Thomas Runge wrote: Hello, I have got some problems using the TableColumnSeparators-property of a SwXTextTableRow-instance. I'm not sure if this could be a bug, so I try - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] CoreReflection - and what can not be queried ...
Marten, Marten Feldtmann wrote: Thanks for all answer ... I'll post my results on this list - if this is interested for you all. this is certainly interesting :-) And, if you are going to contribute it, I suggest to provide pages on the wiki http://wiki.services.openoffice.org/wiki/Uno Marten Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Getting URE types from Java
Hi, Stephan Bergmann wrote: You are probably using com.sun.star.comp.helper.Bootstrap.bootstrap. Despite being included in a URE jar, this is OOo-specific functionality, This is wrong. so it is by design that it fails for you. Poor design indeed, I agree... This is not by design, but by implementation only! -Stephan Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] JVM crash after connection to OpenOffice
Morten, could you try to use TCP/IP instead of Unix sockets (AKA pipes)? The problem may be related to the Unix sockets support library (libjpipe.so) respectively the platform abstraction (libuno_sal). Regards Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Removed dead stuff from URP
Stephan Bergmann wrote: 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. At least ForceSynchronous was quite useful when debugging remote scenarios with async requests. (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 Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Java Add-on and Swing UI.....
Ashok, ashok _ wrote: Hello there: Is it possible to invoke Swing JFrame windows from within a java addon? I Yes. have been unable to do this successfully as the Swing dialog launches, but if i close it and try to launch it again it crashes openoffice do you have a stack trace? Thanks Ashok Regards Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] CH2000 volunteer to do sth. for the UDK project
Hi Stephan, Stephan Bergmann wrote: Thanks for taking interest. Anyway, not directly related to your request, I have some troubles with that todo. Quoting from that wiki page: There are various obstacles in the way to cleanly separate C Uno (AKA Binary Uno) from C++ Uno. Some of these are * the C Uno runtime is implemented in C++, In how far is that a problem? In case that we understand a clean separation of the C and C++ Uno runtimes in a way, that the C++ runtime is implemented on top of the C runtime, than the C runtime may not be implemented by using elements (headers) of the C++. You could argue, that the C runtime may very well use C++ inline stuff from the C++ runtime, which is valid, but please see below. * a C++ Uno runtime would be stacked on top of C Uno, * there is no living C language binding, Do we want one? Yes, I think so. A C runtime likely makes Uno more attractive to other projects. * the C++ Uno runtime offers various functions for bootstrapping Uno, which are not yet available for Binary Uno. Again, do we need them? See above. * Upper level modules headers may not be used, until they are delivered, even if they are self contained. What is meant with that? What I want to say is, that in a lower module you may not use upper level implementations, even in case they are completely inline, as during building the upper levels are not yet delivered. -Stephan Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Changing GUI chrome - Unlisted entries
Terry, did you already ask on the API list? If no one listens their, I would try the framework project ... Just feel free to send me another mail, in case nobody could help. Regards Kay Terry Alexis Lurie wrote: Hi! This may require a redirect to the correct project mailing list which deals with this. In OO Draw 2.04,2.1+ I would like to disable some features without using the mouse. I use UNO to disable a lot, but there are some gui elements I just cannot seem to access via UNO 1) The Pages pane, which I think I have tracked down to .uno:LeftPaneDraw - It is accessible via menubar under View - Page Pane in the EN-UK version of OO - Sorry, but I just cannot figure out what to invoke in UNO to close this - I use the Java UNO 2) The Custom Horizontal Scrollbar - Draw/Impress - In Draw it opens to \ Layout /\ Controls /\ DimensionLines / - I would like to make this an ordinary scrollbar - If that is too difficult, I would like to start Draw with the width of the custom are set to zero - It confuses my Users, who don't rely on that functionality If you could help/redirect me, that would be much appreciated Sincerely, Terry. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] About the task Effort/Clean Up Anachronistic Threading Constructs
Hi Liyuan, Liyuan(Internet) wrote: Hi all, I have read the task of mutli-threading: good! http://wiki.services.openoffice.org/wiki/Effort/Revise_OOo_Multi-Threading The task Effort/Clean Up Anachronistic Threading Constructs is open, Yep, problem is, that it depends on other stuff. Who can give me some information about how to begin with the task? Me :-) Is there any scheme about the task? I roughly would summarize it as: - Remove most mutexes from code. - Remove all main-thread delegations, including the main-thread executor, any post messages etc. - Remove the SolarMutex and is providing APIs. - ... It is basically about removing any constructs which are not needed anymore, after switching to a new threading architecture. Please see http://wiki.services.openoffice.org/wiki/Spec/Threading-Architecture If you give me some time, I am going to define the tasks more fine grained, adding the dependencies as well. In between you may want to take a look at my bunoexttm CWS, which is the foundation for further threading (-architecture) related changes in OOo. Please see my other mail for the details. Regards, Liyuan Thank you very much for your interest Kay -- Sun Microsystems GmbH Kay Ramme Sachsenfeld 4 Senior Technical Architect 20097 Hamburg Phone: (+49 40) 23646 982 Germany Fax: (+49 40) 23646 550 http://www.sun.com/staroffice mailto:[EMAIL PROTECTED] http://www.sun.com/openoffice http://udk.openoffice.org Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Marcel Schneider, 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] Creating UNO-Ruby bridge?
Hi Girish, Girish Chandran wrote: Hi All, I am analyzing the effort required for implementing a UNO Bridge for Ruby. I am happy to hear that :-) As part of this exercise I am going through the documentation available at the following urls: - http://udk.openoffice.org/common/man/bridge.html - http://api.openoffice.org/docs/DevelopersGuide/AdvancedUNO/AdvancedUNO.xhtml All documentation should be reachable from http://wiki.services.openoffice.org/wiki/Uno/Spec respectively http://wiki.services.openoffice.org/wiki/Uno/Articles%26Tutorials I have some experience in working with UNO components but this is the first time I am trying to write a Bridge. I am also going through some of the existing bridges to get some understanding of the design/architecture to be followed when developing a new bridge. It would be really helpful if I can get some pointers in this regards which would speed up my study. Is there any tutorial about writing Bridges? Can some body share their experiences? You actually have the choice to write a * remote Uno or * a Binary Uno bridge, though in theory you could use any language binding for which a bridge already exits (e.g. you could use JRuby and implement the bridge in Java). A remote bridge basically marshalles all requests and sends these through a connection (e.g. TCP/IP) respectively it receives and unmarshalls requests. It needs to manage threads and to preserve thread identities etc. Documentation for Remote Uno is tight and can be found here: http://wiki.services.openoffice.org/wiki/Uno/Remote A Binary Uno bridge would use the Ruby runtime in process. Despite synchronization etc. you wouldn't need to deal with threads or thread pools, but would need to use some Ruby native interface. The PyUno python Uno bridge is implemented as a Binary Uno bridge. You may want to use the PyUno bridge (http://wiki.services.openoffice.org/wiki/Uno/PyUno) as a template. Documentation for Binary Uno can be found here: http://wiki.services.openoffice.org/wiki/Uno/Binary If you are going to create a Ruby bridge, please create a page http://wiki.services.openoffice.org/wiki/Uno/Ruby as the root for documentation. You may also want to create a http://wiki.services.openoffice.org/wiki/Uno/Effort/Create Ruby Bridge for managing the tasks, states etc. thanks and best regards, Girish Best regards Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Re: [udk-cvs] CVS update [cws_src680_os2port02]: /udk/cppuhelper/source/
Yuri, Stephan Bergmann wrote: 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. AFAIR, MinGW needs this as well. So, this may be the right time to generalize the Mac OS X approach ... which, by the way, is relative simple :-) -Stephan Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] OLE, UNO, Memory Management - some hints ?
Marten, Marten Feldtmann wrote: Ok, my code generator for Smalltalk is working pretty well (structs and exceptions are missing), but I have now one problem - I have very large memory leaks (200 MB) on both sides: Smalltalk and OpenOffice .. :-( Perhaps this is more or less an OLE question, but how do I have to handle all these thousands of new automation objects I get with every query -- and how the parameters. Any hints ? don't know too much about OLE, in general Uno objects are all ref counted (w/ the exception of GC based languages as Java), deleting themselves in case the count drops to zero. So, you may want to somehow decrease the ref count when loosing a reference. Marten Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Are you going to discuss about to do it or not?
Cynthia,
regarding the separation of Binary ('C') Uno and C++ Uno, the importance
certainly depends on your goals. And unfortunately especially this item
may require to become ABI or API incompatible, which by now is forbidden.
For Unos acceptance in the FOSS world it actually is quite important to
have clear boundaries between C' and C++, though this actually has only
low importance for Sun currently.
It is for no particular reason that the separation is on top of the Uno
todos list, but for coincidence only.
I plan to rework the todos list soon and to add priorities, to make
navigation and selection easier.
Hope that helps
Kay
Cynthia Qu wrote:
hi, Stephan,
Thank you very much for your explain! And I got it then. :)
hi, Kay,
As the task whether is a useful todo is somewhat controversial, I am not sure
we are going to do it or not.
http://wiki.services.openoffice.org/wiki/Uno/Todo/Clear_Separation_of_C_and_Cpp_and_Core_Components
If it is not useful to do at present, I think I'd better find another task of
the project to do.
Do you have any suggestion about this? Or what can do I for the project?
Thank you very much for all of your support!
Best regards,
Cynthia ^_^
2007-12-11
Stephan Bergmann wrote;
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]
Welcome to China!
Beijing Redflag CH2000 Software Co., Ltd. China
http://www.redflag2000.com.cn/english/index.htm
Re: [udk-dev] Simple Bootstrap
Stephan, 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. thanks for the overview ... 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). I see ... I suggest to sacrifice compatibility and to see how many are starting to scream, only if we feel that these are too many, we should add any compatibility hacks. 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). Again I suggest to sacrifice compatibility and _not_ to add any links, as far as I can tell, the C++ stuff is even less often used then the Java stuff. 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. Same suggestions as for 1) and 2). 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.) Let's go with the clean approach ... 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). I think going with the clean solution is what we should do, a workaround for older code is to manually set the UNO_PATH env. var. to point to the URE. One obvious solution, at least for the Unices, would have been, to put the starters (unoapploader, juh.jar (respectively the loader part of it)), at persistent locations of the target system ... More opinions, anybody? -Stephan Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] create/modify writer docs without running OO
Hi Dan, there is the ODFToolkit project, you may want to have a look at that ... http://odftoolkit.org/ Regards Kay Daniel Elliott wrote: Hello, Thank you to all for this very cool library! I am a bit new and need some guidance. Using the tutorials in the wiki, I now know how to load, modify, and save writer docs using the API. However, we are writing a desktop app that we will distribute and would like to avoid distributing the open office executables (just the api libraries, would be preferable). All I need to do is add a graphic or two and some values in pre-specified locations. Is it possible to do this without using the OO services of a hidden OO instance and just either parse the doc or build an app from scratch using API calls? Thank you. - dan - To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org For additional commands, e-mail: dev-h...@udk.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@udk.openoffice.org For additional commands, e-mail: dev-h...@udk.openoffice.org
